From owner-freebsd-net Sun May 5 15:37:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by hub.freebsd.org (Postfix) with ESMTP id 875C737B415 for ; Sun, 5 May 2002 15:36:58 -0700 (PDT) Received: from fwd04.sul.t-online.de by mailout01.sul.t-online.com with smtp id 174Ucj-0000Ud-03; Mon, 06 May 2002 00:36:57 +0200 Received: from spirit.zuhause.stoert.net (320050403952-0001@[80.128.117.104]) by fmrl04.sul.t-online.com with esmtp id 174Uca-26EJ4CC; Mon, 6 May 2002 00:36:48 +0200 Received: from elevation.zuhause.stoert.net (elevation.zuhause.stoert.net [192.168.66.46]) by spirit.zuhause.stoert.net (8.11.6/8.11.6) with ESMTP id g45MalR77066 for ; Mon, 6 May 2002 00:36:47 +0200 (CEST) (envelope-from corecode@elevation.zuhause.stoert.net) Received: (from corecode@localhost) by elevation.zuhause.stoert.net (8.12.3/8.12.3/Submit) id g45MaiJ7052466; Mon, 6 May 2002 00:36:44 +0200 (CEST) (envelope-from corecode) Date: Mon, 6 May 2002 00:36:40 +0200 From: "Simon 'corecode' Schubert" To: net@freebsd.org Subject: pptp/ppp just closing without reason Message-Id: <20020506003640.7e0f743f.corecode@corecode.ath.cx> X-Mailer: Sylpheed version 0.7.5claws (GTK+ 1.2.10; i386-portbld-freebsd4.5) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=.YLUG7Oa?KLIunQ" X-Sender: 320050403952-0001@t-dialin.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --=.YLUG7Oa?KLIunQ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit hello networkers, i've been trying to set up a pptp tunnel for more than one week now and i wonder why this doesn't work: pptp 129.187.10.28 pptp returns after some seconds. the log indicates the termination of ppp, but why does it terminate? pitty i don't have the server logs May 6 00:27:39 spirit pptp[76897]: log[pptp_dispatch_ctrl_packet:pptp_ctrl.c:548]: Client connection established. May 6 00:27:40 spirit pptp[76897]: log[pptp_dispatch_ctrl_packet:pptp_ctrl.c:655]: Outgoing call established (call ID 0, peer's call ID 0). May 6 00:27:40 spirit ppp[76895]: Phase: Using interface: tun1 May 6 00:27:40 spirit ppp[76895]: Phase: deflink: Created in closed state May 6 00:27:40 spirit ppp[76895]: tun1: Phase: PPP Started (direct mode). May 6 00:27:40 spirit ppp[76895]: tun1: Phase: bundle: Establish May 6 00:27:40 spirit ppp[76895]: tun1: Phase: deflink: closed -> opening May 6 00:27:40 spirit ppp[76895]: tun1: Phase: deflink: Connected! May 6 00:27:40 spirit ppp[76895]: tun1: Phase: deflink: opening -> carrier May 6 00:27:41 spirit ppp[76895]: tun1: Phase: deflink: carrier -> lcp May 6 00:27:41 spirit ppp[76895]: tun1: LCP: FSM: Using "deflink" as a transport May 6 00:27:41 spirit ppp[76895]: tun1: LCP: deflink: State change Initial --> Closed May 6 00:27:41 spirit ppp[76895]: tun1: LCP: deflink: State change Closed --> Stopped May 6 00:27:42 spirit ppp[76895]: tun1: LCP: deflink: LayerStart May 6 00:27:42 spirit ppp[76895]: tun1: LCP: deflink: SendConfigReq(1) state = Stopped May 6 00:27:42 spirit ppp[76895]: tun1: LCP: ACFCOMP[2] May 6 00:27:42 spirit ppp[76895]: tun1: LCP: PROTOCOMP[2] May 6 00:27:42 spirit ppp[76895]: tun1: LCP: ACCMAP[6] 0x00000000 May 6 00:27:42 spirit ppp[76895]: tun1: LCP: MRU[4] 1500 May 6 00:27:42 spirit ppp[76895]: tun1: LCP: MAGICNUM[6] 0x94759594 May 6 00:27:42 spirit ppp[76895]: tun1: LCP: deflink: State change Stopped --> Req-Sent May 6 00:27:45 spirit ppp[76895]: tun1: LCP: deflink: SendConfigReq(1) state = Req-Sent May 6 00:27:45 spirit ppp[76895]: tun1: LCP: ACFCOMP[2] May 6 00:27:45 spirit ppp[76895]: tun1: LCP: PROTOCOMP[2] May 6 00:27:45 spirit ppp[76895]: tun1: LCP: ACCMAP[6] 0x00000000 May 6 00:27:45 spirit ppp[76895]: tun1: LCP: MRU[4] 1500 May 6 00:27:45 spirit ppp[76895]: tun1: LCP: MAGICNUM[6] 0x94759594 May 6 00:27:45 spirit ppp[76895]: tun1: LCP: deflink: RecvConfigAck(1) state = Req-Sent May 6 00:27:45 spirit ppp[76895]: tun1: LCP: deflink: State change Req-Sent --> Ack-Rcvd May 6 00:27:46 spirit ppp[76895]: tun1: LCP: deflink: RecvConfigReq(1) state = Ack-Rcvd May 6 00:27:46 spirit ppp[76895]: tun1: LCP: ACCMAP[6] 0x00000000 May 6 00:27:46 spirit ppp[76895]: tun1: LCP: AUTHPROTO[4] 0xc023 (PAP) May 6 00:27:46 spirit ppp[76895]: tun1: LCP: MAGICNUM[6] 0xb2cad472 May 6 00:27:46 spirit ppp[76895]: tun1: LCP: PROTOCOMP[2] May 6 00:27:46 spirit ppp[76895]: tun1: LCP: ACFCOMP[2] May 6 00:27:46 spirit ppp[76895]: tun1: LCP: deflink: SendConfigAck(1) state = Ack-Rcvd May 6 00:27:46 spirit ppp[76895]: tun1: LCP: ACCMAP[6] 0x00000000 May 6 00:27:46 spirit ppp[76895]: tun1: LCP: AUTHPROTO[4] 0xc023 (PAP) May 6 00:27:46 spirit ppp[76895]: tun1: LCP: MAGICNUM[6] 0xb2cad472 May 6 00:27:46 spirit ppp[76895]: tun1: LCP: PROTOCOMP[2] May 6 00:27:46 spirit ppp[76895]: tun1: LCP: ACFCOMP[2] May 6 00:27:46 spirit ppp[76895]: tun1: LCP: deflink: State change Ack-Rcvd --> Opened May 6 00:27:46 spirit ppp[76895]: tun1: LCP: deflink: LayerUp May 6 00:27:46 spirit ppp[76895]: tun1: Phase: bundle: Authenticate May 6 00:27:46 spirit ppp[76895]: tun1: Phase: deflink: his = PAP, mine = none May 6 00:27:46 spirit ppp[76895]: tun1: Phase: Pap Output: simons@eikon ******** May 6 00:27:46 spirit ppp[76895]: tun1: Phase: Pap Input: SUCCESS (Success) May 6 00:27:46 spirit ppp[76895]: tun1: CCP: FSM: Using "deflink" as a transport May 6 00:27:46 spirit ppp[76895]: tun1: CCP: deflink: State change Initial --> Closed May 6 00:27:46 spirit ppp[76895]: tun1: CCP: deflink: State change Closed --> Stopped May 6 00:27:46 spirit ppp[76895]: tun1: Phase: deflink: lcp -> open May 6 00:27:46 spirit ppp[76895]: tun1: Phase: bundle: Network May 6 00:27:46 spirit ppp[76895]: tun1: IPCP: FSM: Using "deflink" as a transport May 6 00:27:46 spirit ppp[76895]: tun1: IPCP: deflink: State change Initial --> Closed May 6 00:27:46 spirit ppp[76895]: tun1: IPCP: deflink: LayerStart. May 6 00:27:46 spirit ppp[76895]: tun1: IPCP: deflink: SendConfigReq(1) state = Closed May 6 00:27:46 spirit ppp[76895]: tun1: IPCP: IPADDR[6] 0.0.0.0 May 6 00:27:46 spirit ppp[76895]: tun1: IPCP: COMPPROTO[6] 16 VJ slots with slot compression May 6 00:27:46 spirit ppp[76895]: tun1: IPCP: deflink: State change Closed --> Req-Sent May 6 00:27:46 spirit ppp[76895]: tun1: IPCP: deflink: RecvConfigReq(1) state = Req-Sent May 6 00:27:46 spirit ppp[76895]: tun1: IPCP: IPADDR[6] 129.187.10.28 May 6 00:27:46 spirit ppp[76895]: tun1: IPCP: COMPPROTO[6] 16 VJ slots with slot compression May 6 00:27:46 spirit ppp[76895]: tun1: IPCP: deflink: SendConfigAck(1) state = Req-Sent May 6 00:27:46 spirit ppp[76895]: tun1: IPCP: IPADDR[6] 129.187.10.28 May 6 00:27:46 spirit ppp[76895]: tun1: IPCP: COMPPROTO[6] 16 VJ slots with slot compression May 6 00:27:46 spirit ppp[76895]: tun1: IPCP: deflink: State change Req-Sent --> Ack-Sent May 6 00:27:46 spirit ppp[76895]: tun1: CCP: deflink: RecvConfigReq(1) state = Stopped May 6 00:27:46 spirit ppp[76895]: tun1: CCP: DEFLATE[4] win 15 May 6 00:27:46 spirit ppp[76895]: tun1: CCP: MAGNALINK/DEFLATE[4] win 15 May 6 00:27:46 spirit ppp[76895]: tun1: CCP: BSD[3] May 6 00:27:46 spirit ppp[76895]: tun1: CCP: deflink: SendConfigReq(1) state = Stopped May 6 00:27:46 spirit ppp[76895]: tun1: CCP: [EMPTY] May 6 00:27:46 spirit ppp[76895]: tun1: CCP: deflink: SendConfigRej(1) state = Stopped May 6 00:27:46 spirit ppp[76895]: tun1: CCP: MAGNALINK/DEFLATE[4] win 15 May 6 00:27:46 spirit ppp[76895]: tun1: CCP: BSD[3] May 6 00:27:46 spirit ppp[76895]: tun1: CCP: deflink: LayerStart. May 6 00:27:46 spirit ppp[76895]: tun1: CCP: deflink: State change Stopped --> Req-Sent May 6 00:27:46 spirit ppp[76895]: tun1: IPCP: deflink: RecvConfigNak(1) state = Ack-Sent May 6 00:27:46 spirit ppp[76895]: tun1: IPCP: IPADDR[6] 129.187.48.18 May 6 00:27:46 spirit ppp[76895]: tun1: IPCP: IPADDR[6] changing address: 0.0.0.0 --> 129.187.48.18 May 6 00:27:46 spirit ppp[76895]: tun1: IPCP: deflink: SendConfigReq(2) state = Ack-Sent May 6 00:27:46 spirit ppp[76895]: tun1: IPCP: IPADDR[6] 129.187.48.18 May 6 00:27:46 spirit ppp[76895]: tun1: IPCP: COMPPROTO[6] 16 VJ slots with slot compression May 6 00:27:46 spirit ppp[76895]: tun1: CCP: deflink: RecvConfigAck(1) state = Req-Sent May 6 00:27:46 spirit ppp[76895]: tun1: CCP: deflink: State change Req-Sent --> Ack-Rcvd May 6 00:27:46 spirit ppp[76895]: tun1: IPCP: deflink: RecvConfigAck(2) state = Ack-Sent May 6 00:27:46 spirit ppp[76895]: tun1: IPCP: deflink: State change Ack-Sent --> Opened May 6 00:27:46 spirit ppp[76895]: tun1: IPCP: deflink: LayerUp. May 6 00:27:46 spirit ppp[76895]: tun1: IPCP: myaddr 129.187.48.18 hisaddr = 129.187.10.28 May 6 00:27:49 spirit ppp[76895]: tun1: CCP: deflink: RecvConfigReq(1) state = Ack-Rcvd May 6 00:27:49 spirit ppp[76895]: tun1: CCP: DEFLATE[4] win 15 May 6 00:27:49 spirit ppp[76895]: tun1: CCP: MAGNALINK/DEFLATE[4] win 15 May 6 00:27:49 spirit ppp[76895]: tun1: CCP: BSD[3] May 6 00:27:49 spirit ppp[76895]: tun1: CCP: deflink: SendConfigRej(1) state = Ack-Rcvd May 6 00:27:49 spirit ppp[76895]: tun1: CCP: MAGNALINK/DEFLATE[4] win 15 May 6 00:27:49 spirit ppp[76895]: tun1: CCP: BSD[3] May 6 00:27:50 spirit ppp[76895]: tun1: Phase: Signal 15, terminate. May 6 00:27:50 spirit ppp[76895]: tun1: IPCP: deflink: LayerDown: 129.187.48.18 May 6 00:27:50 spirit ppp[76895]: tun1: IPCP: deflink: SendTerminateReq(3) state = Opened May 6 00:27:50 spirit ppp[76895]: tun1: IPCP: deflink: State change Opened --> Closing May 6 00:27:50 spirit ppp[76895]: tun1: Phase: deflink: read (0): Got zero bytes May 6 00:27:50 spirit ppp[76895]: tun1: CCP: deflink: State change Ack-Rcvd --> Starting May 6 00:27:50 spirit ppp[76895]: tun1: CCP: deflink: LayerFinish. May 6 00:27:50 spirit ppp[76895]: tun1: CCP: deflink: State change Starting --> Initial May 6 00:27:50 spirit ppp[76895]: tun1: LCP: deflink: LayerDown May 6 00:27:50 spirit ppp[76895]: tun1: LCP: deflink: State change Opened --> Starting May 6 00:27:50 spirit ppp[76895]: tun1: Phase: deflink: open -> lcp May 6 00:27:50 spirit ppp[76895]: tun1: IPCP: deflink: LayerFinish. May 6 00:27:50 spirit ppp[76895]: tun1: IPCP: Connect time: 4 secs: 0 octets in, 812035 octets out May 6 00:27:50 spirit ppp[76895]: tun1: IPCP: : 0 packets in, 1573 packets out May 6 00:27:50 spirit ppp[76895]: tun1: IPCP: total 203008 bytes/sec, peak 135942 bytes/sec on Mon May 6 00:27:50 2002 May 6 00:27:50 spirit ppp[76895]: tun1: IPCP: deflink: State change Closing --> Initial May 6 00:27:50 spirit ppp[76895]: tun1: Phase: bundle: Terminate May 6 00:27:50 spirit ppp[76895]: tun1: LCP: deflink: LayerFinish May 6 00:27:50 spirit ppp[76895]: tun1: LCP: deflink: State change Starting --> Initial May 6 00:27:50 spirit ppp[76895]: tun1: Phase: deflink: Disconnected! May 6 00:27:50 spirit ppp[76895]: tun1: Phase: deflink: Connect time: 10 secs: 298 octets in, 820693 octets out May 6 00:27:50 spirit ppp[76895]: tun1: Phase: deflink: : 8 packets in, 1584 packets out May 6 00:27:50 spirit ppp[76895]: tun1: Phase: total 82099 bytes/sec, peak 122307 bytes/sec on Mon May 6 00:27:50 2002 May 6 00:27:50 spirit ppp[76895]: tun1: Phase: deflink: lcp -> closed May 6 00:27:50 spirit ppp[76895]: tun1: Phase: bundle: Dead May 6 00:27:50 spirit ppp[76895]: tun1: Phase: PPP Terminated (normal). May 6 00:27:50 spirit pptp[76897]: log[callmgr_main:pptp_callmgr.c:240]: Closing connection May 6 00:27:50 spirit pptp[76897]: log[pptp_conn_close:pptp_ctrl.c:285]: Closing PPTP connection May 6 00:27:52 spirit pptp[76897]: log[call_callback:pptp_callmgr.c:88]: Closing connection my config looks like this: pptp: set authname "simons@eikon" set authkey "XXXXX" set timeout 0 set ifaddr 0.0.0.0/0 disable mppe deny mppe accept deflate24 disable pred1 disable deflate set log Phase Chat Connect LCP IPCP CCP tun Warning Error command alert #debug pppoe works just fine from this machine. i really don't see why there is this Phase: Signal 15, terminate. seems ppp receives a SIGTERM from somewhere... i hope you can help me simon ps: i also don't understand why it keeps rejecting MAGNALINK/DEFLATE though i'm accepting deflate24. -- /"\ http://corecode.ath.cx/#donate \ / \ ASCII Ribbon Campaign / \ Against HTML Mail and News --=.YLUG7Oa?KLIunQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) iD8DBQE81bP8r5S+dk6z85oRAoQ6AJkBYLQAgbBHQCcXzJC+8KgfaNAeowCgstcG 2zBu+2lYPOntpO8gaa3SqeM= =vIpk -----END PGP SIGNATURE----- --=.YLUG7Oa?KLIunQ-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 6 1:45:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.airnet.com.au (mail.airnet.com.au [202.174.32.5]) by hub.freebsd.org (Postfix) with SMTP id CFB9437B407 for ; Mon, 6 May 2002 01:45:17 -0700 (PDT) Received: (qmail 18883 invoked from network); 6 May 2002 08:45:14 -0000 Received: from ppp411.ar1.adl1.airnet.com.au (HELO bender) (202.174.35.155) by mail.airnet.com.au with SMTP; 6 May 2002 08:45:14 -0000 From: "Martin Minkus" To: Subject: 802.11: WaveLAN/Orinoco Cards Date: Mon, 6 May 2002 18:14:44 +0930 Message-ID: <005601c1f4da$56ab0160$0200000a@bender> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0057_01C1F529.F774DD60" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3621.0 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0057_01C1F529.F774DD60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Okay, i am getting some wierd stuff with this :) I got a WinXP client running the Orinico Client manager, and am watching what speed the FreeBSD machine is sending me packets at. silence:~# wicontrol -t 5 With that option set, lets play with ifconfig. silence:~# ifconfig wi0 media DS/1Mbps Okay. This sends at 1mbps, as expected. silence:~# ifconfig wi0 media DS/2Mbps Okay. This sends at 2mbps, as expected. silence:~# ifconfig wi0 media DS/5.5Mbps This sends at 11mbps. WTF?! What happened to 5.5? silence:~# ifconfig wi0 media DS/11Mbps This sends at 2mbps. Again, WTF? What happened to 11? Lets set it to: silence:~# ifconfig wi0 media DS/5.5Mbps And now play with wicontrol.... silence:~# wicontrol -t 1 Does it at 1mbit. Well, expected i think. Says 1mbps in the manual page. silence:~# wicontrol -t 2 Does it at 2mbit. Also expected. silence:~# wicontrol -t 4 Does it at 5.5mbit. Manual page says 4mbit (never mind there is no such thing as 4mbit) silence:~# wicontrol -t 5 Does it at 11mbit. Manual page says 6mbit (never mind there is no such thing as 6mbit). silence:~# wicontrol -t 3 Does it at 11mbit. Manual page says it auto rate select high. So, um, why all this insanity? Do i just stick to putting wicontrol -t 5 and ifconfig media DS/5.5mbps? I've tried various orinico cards, and they all exhbit this behaviour... What confuses me is, why make it possible to select speeds via ifconfig AND wicontrol? Why not just one place? Any ideas? Any explanations? Martin. PS. make sure you include me in the TO/CC field as i am not on the mailing list. ------=_NextPart_000_0057_01C1F529.F774DD60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Okay, = i am getting=20 some wierd stuff with this :)
 
I got = a WinXP client=20 running the Orinico Client manager, and am watching what speed the = FreeBSD=20 machine is sending me packets at.
 
silence:~# wicontrol=20 -t 5
 
With = that option=20 set, lets play with ifconfig.
 
silence:~# ifconfig=20 wi0 media DS/1Mbps
 
Okay. This sends at 1mbps, as=20 expected.
 
silence:~# ifconfig=20 wi0 media DS/2Mbps
 
Okay. = This sends at=20 2mbps, as expected.
 
silence:~# ifconfig wi0 media=20 DS/5.5Mbps
 
This = sends at=20 11mbps. WTF?! What happened to 5.5?
 
silence:~# ifconfig wi0 media=20 DS/11Mbps
 
This=20 sends at 2mbps. Again, WTF? What happened to = 11?
 
 
Lets=20 set it to:
 
silence:~# ifconfig wi0 = media=20 DS/5.5Mbps
 
And=20 now play with wicontrol....
 
silence:~# wicontrol -t 1
Does=20 it at 1mbit. Well, expected i think. Says 1mbps in the manual=20 page.
 
silence:~# wicontrol -t 2
 
Does=20 it at 2mbit. Also expected.

silence:~# wicontrol -t = 4
 
Does it at 5.5mbit. Manual page says 4mbit = (never mind=20 there is no such thing as 4mbit)

silence:~# wicontrol -t = 5
Does = it at 11mbit.=20 Manual page says 6mbit (never mind there is no such thing as=20 6mbit).
 
silence:~# wicontrol -t=20 3
 
Does=20 it at 11mbit. Manual page says it auto rate select=20 high.
 
 
So,=20 um, why all this insanity?
 
Do i=20 just stick to putting wicontrol -t 5 and ifconfig media=20 DS/5.5mbps?
 
I've=20 tried various orinico cards, and they all exhbit this behaviour... What = confuses=20 me is, why make it possible to select speeds via ifconfig AND wicontrol? = Why not=20 just one place?
 
Any=20 ideas? Any explanations?
 
Martin.
 
PS.=20 make sure you include me in the TO/CC field as i am not on the mailing=20 list.
 
 ------=_NextPart_000_0057_01C1F529.F774DD60-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 6 1:56:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.airnet.com.au (mail.airnet.com.au [202.174.32.5]) by hub.freebsd.org (Postfix) with SMTP id 742AA37B407 for ; Mon, 6 May 2002 01:56:22 -0700 (PDT) Received: (qmail 19566 invoked from network); 6 May 2002 08:56:19 -0000 Received: from ppp411.ar1.adl1.airnet.com.au (HELO bender) (202.174.35.155) by mail.airnet.com.au with SMTP; 6 May 2002 08:56:19 -0000 From: "Martin Minkus" To: "'Terry Lambert'" Cc: , Subject: RE: 802.11: WaveLAN/Orinoco Cards Date: Mon, 6 May 2002 18:25:46 +0930 Message-ID: <005b01c1f4db$e3563f20$0200000a@bender> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3621.0 In-Reply-To: <3CD643F6.33680AA3@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 But it's a standard WaveLAN/Orinico card, which is what the wi driver is intended for? I never had to worry about any of this when I had the old white/bronze 2mbit wavelan cards, but with silver and gold cards, its been nothing but fun and games.... -----Original Message----- From: Terry Lambert [mailto:tlambert2@mindspring.com] Sent: Monday, 6 May 2002 18:21 To: Martin Minkus Cc: freebsd-network@freebsd.org; freebsd-hackers@freebsd.org Subject: Re: 802.11: WaveLAN/Orinoco Cards Martin Minkus wrote: > > Part 1.1 Type: Plain Text (text/plain) > Encoding: 7bit [ ... data rate controls on the ifconfig or wicontrol command lines tend to result in unexpexted -- frequently 11Mbit rather than lower -- measured speeds ... ] I guess you will have to "suffer" with higher than expected data rates? 8-) 8-). Actually, I think it's because the card you are using has a different set of mappings than the firmware for which the commands were intended, and the driver you are using (wi0) "happens" to work with the card, despite the different firmware. but the "magic" features don't. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 6 9: 6:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from quack.kfu.com (adsl-67-113-12-90.dsl.snfc21.pacbell.net [67.113.12.90]) by hub.freebsd.org (Postfix) with ESMTP id 0444E37B50C for ; Mon, 6 May 2002 09:05:05 -0700 (PDT) Received: from morpheus.kfu.com (morpheus.kfu.com [3ffe:1200:301b:1:2d0:b7ff:fe3f:bdd0]) by quack.kfu.com (8.11.6/8.11.6) with ESMTP id g46G4ts72094 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 6 May 2002 09:05:00 -0700 (PDT) (envelope-from nsayer@quack.kfu.com) Received: from quack.kfu.com (nospam@localhost [::1]) by morpheus.kfu.com (8.11.6/8.11.6) with ESMTP id g46G4sO01361 for ; Mon, 6 May 2002 09:04:54 -0700 (PDT) (envelope-from nsayer@quack.kfu.com) Message-ID: <3CD6A9A6.6010205@quack.kfu.com> Date: Mon, 06 May 2002 09:04:54 -0700 From: Nick Sayer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020312 X-Accept-Language: en, en-US, en-GB MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG 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; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bill Fumerola wrote: > [ 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? > I believe IPv6 anycasting could be a solution for this sort of thing. The front end could serve as a reverse NATPT mapping to an anycast address. Of course, I've never set up anycasting, so I am mostly talking through my hat. :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 6 9:33:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id D2DCC37B400; Mon, 6 May 2002 09:33:32 -0700 (PDT) Received: from pool0013.cvx22-bradley.dialup.earthlink.net ([209.179.198.13] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 174lQT-00024M-00; Mon, 06 May 2002 09:33:26 -0700 Message-ID: <3CD6B038.3E487B@mindspring.com> Date: Mon, 06 May 2002 09:32:56 -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: Martin Minkus Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: 802.11: WaveLAN/Orinoco Cards References: <005b01c1f4db$e3563f20$0200000a@bender> 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 Martin Minkus wrote: > But it's a standard WaveLAN/Orinico card, which is what the wi driver is > intended for? > > I never had to worry about any of this when I had the old white/bronze > 2mbit wavelan cards, but with silver and gold cards, its been nothing > but fun and games.... I suppose I can understand wanting to control the data rate manually because you can, rather than just being happy it works at the highest data rate... The only thing I could suggest would be to contact the driver author directly and/or sign an NDA and get the programming docs yourself. I'm pretty sure Julian could answer yes/no questions about the card speed setttings. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 6 9:41:26 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 736D137B408 for ; Mon, 6 May 2002 09:41:14 -0700 (PDT) Received: (from tinguely@localhost) by web.cs.ndsu.nodak.edu (8.11.4/8.11.4) id g46GfCX78428; Mon, 6 May 2002 11:41:13 -0500 (CDT) (envelope-from tinguely) Date: Mon, 6 May 2002 11:41:13 -0500 (CDT) From: mark tinguely Message-Id: <200205061641.g46GfCX78428@web.cs.ndsu.nodak.edu> To: bwhite@moab.cs.utah.edu, freebsd-net@FreeBSD.ORG Subject: Re: FBSD 4.3 New Reno Fast Retransmit Behavior In-Reply-To: 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 > 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)) { yes, this is a problem because FreeBSD 4.[34 and before?] did not always initialized tp->snd_recover on the session startup and presented a problem when the initial segment sequence is greater than 0x7fffffff. The only other way to tigger this error is if you went half way through the sequence without a duplicate ack. We talked about this a little on -net and decided the prevention would have more overhead than it would effectively cure. FreeBSD 4.5 and greater fixed the initialization of snd_recover with the addition of the "syncache" code. FreeBSD 4.5 also fixed some serious socket errors that would cause more even greater performance problems. I suggest you upgrade. --mark tinguely. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 6 11:17:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id 5649A37B404; Mon, 6 May 2002 11:17:25 -0700 (PDT) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.6/8.11.6) id g46IGDq60379; Mon, 6 May 2002 20:16:13 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200205061816.g46IGDq60379@zibbi.icomtek.csir.co.za> Subject: Re: 802.11: WaveLAN/Orinoco Cards In-Reply-To: <3CD6B038.3E487B@mindspring.com> from Terry Lambert at "May 6, 2002 09:32:56 am" To: tlambert2@mindspring.com (Terry Lambert) Date: Mon, 6 May 2002 20:16:12 +0200 (SAT) Cc: diskiller@diskiller.net (Martin Minkus), freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Martin Minkus wrote: > > But it's a standard WaveLAN/Orinico card, which is what the wi driver is > > intended for? > > > > I never had to worry about any of this when I had the old white/bronze > > 2mbit wavelan cards, but with silver and gold cards, its been nothing > > but fun and games.... > > I suppose I can understand wanting to control the data rate > manually because you can, rather than just being happy it > works at the highest data rate... > > The only thing I could suggest would be to contact the driver > author directly and/or sign an NDA and get the programming > docs yourself. I'm pretty sure Julian could answer yes/no > questions about the card speed setttings. > Nothing as drastic as that. It is/was a bug and has been fixed: revision 1.100 date: 2002/04/14 23:18:40; author: brooks; state: Exp; lines: +15 -0 Fix tx-rate setting for Lucent cards. John -- John Hay -- John.Hay@icomtek.csir.co.za / jhay@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 6 14:48:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by hub.freebsd.org (Postfix) with ESMTP id 3D6FF37B401 for ; Mon, 6 May 2002 14:48:22 -0700 (PDT) Received: from fwd07.sul.t-online.de by mailout04.sul.t-online.com with smtp id 174qLE-0000og-07; Mon, 06 May 2002 23:48:20 +0200 Received: from spirit.zuhause.stoert.net (320050403952-0001@[217.224.166.67]) by fmrl07.sul.t-online.com with esmtp id 174qLA-1WUUyGC; Mon, 6 May 2002 23:48:16 +0200 Received: from elevation.zuhause.stoert.net (elevation.zuhause.stoert.net [192.168.66.46]) by spirit.zuhause.stoert.net (8.11.6/8.11.6) with ESMTP id g46LmFR39626 for ; Mon, 6 May 2002 23:48:15 +0200 (CEST) (envelope-from corecode@elevation.zuhause.stoert.net) Received: (from corecode@localhost) by elevation.zuhause.stoert.net (8.12.3/8.12.3/Submit) id g46LmE0c058754; Mon, 6 May 2002 23:48:14 +0200 (CEST) (envelope-from corecode) Date: Mon, 6 May 2002 23:48:10 +0200 From: "Simon 'corecode' Schubert" To: net@freebsd.org Subject: Re: pptp/ppp just closing without reason Message-Id: <20020506234810.4e97f279.corecode@corecode.ath.cx> In-Reply-To: <20020506003640.7e0f743f.corecode@corecode.ath.cx> References: <20020506003640.7e0f743f.corecode@corecode.ath.cx> X-Mailer: Sylpheed version 0.7.5claws (GTK+ 1.2.10; i386-portbld-freebsd4.5) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="X)uD7_BC6CtVqM=." X-Sender: 320050403952-0001@t-dialin.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --X)uD7_BC6CtVqM=. Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit hey, okay, please ignore my previous post... i sniffed around and found out that the ppp process was kill(TERM)'ed by pptp itself. wondering why this happened led to this conclusion: the pptp server is wrong configured. it's address may be `vpngw1'. it also tells `vpngw1' as peer address for the ppp session. this means that a routing loop is produced: packets that are destined for vpngw1 (peer) are tunneled to vpngw1 (tunnel endpoint). but this again means that this packed is destined for vpngw1 - the packet in turn must be tunneled. mpd rejects this by noting "would cause routing loop". freebsd itself notes that by stating "resource lock avoided" and denying routing of such packets. this was the reason pptp couldn't send GRE packets and quit without failure notice. thanks for your attention, simon -- /"\ http://corecode.ath.cx/#donate \ / \ ASCII Ribbon Campaign / \ Against HTML Mail and News --X)uD7_BC6CtVqM=. Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE81vodr5S+dk6z85oRAmM8AJ43LUudGHWZBKhSh7eoeQhi1Db2iQCgsw81 Vx460eyW7M1v9Jd7Xmficjk= =sxr9 -----END PGP SIGNATURE----- --X)uD7_BC6CtVqM=.-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 6 15: 0:34 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 4A6E737B404 for ; Mon, 6 May 2002 15:00:03 -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 OAA09962; Mon, 6 May 2002 14:54:08 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g46Ls8U15813; Mon, 6 May 2002 14:54:08 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200205062154.g46Ls8U15813@arch20m.dellroad.org> Subject: Re: pptp/ppp just closing without reason In-Reply-To: <20020506234810.4e97f279.corecode@corecode.ath.cx> "from Simon 'corecode' Schubert at May 6, 2002 11:48:10 pm" To: "Simon 'corecode' Schubert" Date: Mon, 6 May 2002 14:54:08 -0700 (PDT) Cc: 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 Simon 'corecode' Schubert writes: > the pptp server is wrong configured. it's address may be `vpngw1'. it > also tells `vpngw1' as peer address for the ppp session. this means that > a routing loop is produced: packets that are destined for vpngw1 (peer) > are tunneled to vpngw1 (tunnel endpoint). but this again means that this > packed is destined for vpngw1 - the packet in turn must be tunneled. > > mpd rejects this by noting "would cause routing loop". freebsd itself > notes that by stating "resource lock avoided" and denying routing of > such packets. > this was the reason pptp couldn't send GRE packets and quit without > failure notice. With mpd-3.8, you should be able to get this to work. In 3.8 mpd no longer prevents you from negotiating the same internal and external IP address for the PPTP tunnel. However you must first install a host route for the remote PPTP server. That way, the PPTP packets will get routed directly instead of through the PPTP tunnel (which is typically the route for the default route). -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 6 15:10:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id EE39D37B48B for ; Mon, 6 May 2002 15:09:09 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.3/8.12.3) with ESMTP id g46M99EN070649 for ; Mon, 6 May 2002 18:09:09 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.3/8.12.3/Submit) id g46M99N8070646; Mon, 6 May 2002 18:09:09 -0400 (EDT) Date: Mon, 6 May 2002 18:09:09 -0400 (EDT) From: Garrett Wollman Message-Id: <200205062209.g46M99N8070646@khavrinen.lcs.mit.edu> To: net@freebsd.org Subject: Junior network hacker tasks... 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 Currently, FreeBSD's implementation of RFC 1323 uses the contents of the `ticks' variable verbatim in the TCP timestamp options that it generates. This is perhaps undesirable, in that it allows the system at the other end to determine how long the system has been up. (Current versions of `nmap' do this.) Also, there are ordered comparisons done throughout the TCP implementation which will break should `ticks' ever wrap around; with high values of `HZ' it is possible for (the 32-bit truncation of) `ticks' to wrap over even relatively small periods of time (e.g., five days for HZ=10000). The following would both be useful activities: 1) Change the RFC 1323 implementation to use ticks relative to the time the socket was created. This is fairly easy to do and requires changes to only a handful of lines of code. (Keep in mind that only timestamps we send over the network ought to be so treated -- the timestamps stored in the TCPCB are a separate issue.) For additional confusion value, consider adding a random bias when each connection is created. (TCP already bogusly depends on a maximum segment lifetime of 30 seconds, so segments dallying in the network for days are probably not a concern. The correct answer for the user who has set HZ to 1000000 is ``don't do that, then'' -- but this probably ought to be documented as a limitation.) 2) Examine the places where the TCP stack references `ticks' for other reasons, and determine whether TCP would fail to operate correctly should `ticks' wrap around. How likely are such failures? Would it help if `ticks' (and derived values) were stored in a wider data type? In some cases, the wrap-around interval is impossibly long with respect to other timeouts, so there is not necessarily a problem in all cases. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 6 15:25:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d15.as28.nwbl0.wi.voyager.net [169.207.69.15]) by hub.freebsd.org (Postfix) with ESMTP id BCF2837B40C for ; Mon, 6 May 2002 15:25:28 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.3/8.12.3) with ESMTP id g46MQPUm062148; Mon, 6 May 2002 17:26:25 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.3/8.12.3/Submit) with ESMTP id g46MQLH5062145; Mon, 6 May 2002 17:26:23 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Mon, 6 May 2002 17:26:20 -0500 (CDT) From: Mike Silbersack To: Garrett Wollman Cc: net@freebsd.org Subject: Re: Junior network hacker tasks... In-Reply-To: <200205062209.g46M99N8070646@khavrinen.lcs.mit.edu> Message-ID: <20020506171825.P60840-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 6 May 2002, Garrett Wollman wrote: > 1) Change the RFC 1323 implementation to use ticks relative to the > time the socket was created. This is fairly easy to do and requires > changes to only a handful of lines of code. (Keep in mind that only > timestamps we send over the network ought to be so treated -- the > timestamps stored in the TCPCB are a separate issue.) For additional > confusion value, consider adding a random bias when each connection is > created. (TCP already bogusly depends on a maximum segment lifetime > of 30 seconds, so segments dallying in the network for days are > probably not a concern. The correct answer for the user who has set > HZ to 1000000 is ``don't do that, then'' -- but this probably ought to > be documented as a limitation.) Is doing this wise? I have this nagging feeling that randomizing (or zeroing on each new connection) the timestamp would degrade its usefulness for PAWS checks and the like. (Don't ask me how, I haven't thought it through fully.) How about this idea: - For inbound connections, use 0 as the start value for the timestamp, as you suggest above. - For outbound connections, generate the timestamp offset using a hash similar to the one used for ISN generation. This way, timestamps won't jump around when connections are broken and reestablished / etc. This is a slight information leak; one can tell that the machine hasn't been rebooted. However, you would have to poll the machine quite often to figure out what the uptime really is. I think that the solution to wrapround with "ticks" is to normalize the value using hz to some known amount. I could certainly code these changes up (I've been thinking along the same lines for a while), but I'd be more than happy to defer to some unknown lurker on the mailing list who wants to make a name for his/her self. :) Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 6 15:53:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 524C737B403 for ; Mon, 6 May 2002 15:53:33 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.3/8.12.3) with ESMTP id g46MrWEN071725; Mon, 6 May 2002 18:53:32 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.3/8.12.3/Submit) id g46MrWiY071722; Mon, 6 May 2002 18:53:32 -0400 (EDT) Date: Mon, 6 May 2002 18:53:32 -0400 (EDT) From: Garrett Wollman Message-Id: <200205062253.g46MrWiY071722@khavrinen.lcs.mit.edu> To: Mike Silbersack Cc: net@freebsd.org Subject: Re: Junior network hacker tasks... In-Reply-To: <20020506171825.P60840-100000@patrocles.silby.com> References: <200205062209.g46M99N8070646@khavrinen.lcs.mit.edu> <20020506171825.P60840-100000@patrocles.silby.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 < said: > Is doing this wise? I have this nagging feeling that randomizing (or > zeroing on each new connection) the timestamp would degrade its usefulness > for PAWS checks and the like. (Don't ask me how, I haven't thought it > through fully.) I don't think so, because the timestamps, as currently specified, are only meaningful within the context of a single connection. See sections 1.2, 4.3, and 4.2 of RFC 1323. The PAWS mechanism requires only that timestamps used by each connection be monotone increasing with respect to Sequence Number Arithmetic. RFC 1323 does require (section 4.2.2) that the clock be between 1 ms and 1 s in period, which I think we already violate on some platforms, although not seriously; there probably should be a pre-computed (global) scaling factor as well. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 6 17:30:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.airnet.com.au (mail.airnet.com.au [202.174.32.5]) by hub.freebsd.org (Postfix) with SMTP id 6015B37B406 for ; Mon, 6 May 2002 17:30:36 -0700 (PDT) Received: (qmail 25700 invoked from network); 7 May 2002 00:30:27 -0000 Received: from ppp126.ar1.adl1.airnet.com.au (HELO bender) (202.174.34.126) by mail.airnet.com.au with SMTP; 7 May 2002 00:30:27 -0000 From: "Martin Minkus" To: "'Terry Lambert'" Cc: , Subject: RE: 802.11: WaveLAN/Orinoco Cards Date: Tue, 7 May 2002 09:59:59 +0930 Message-ID: <006501c1f55e$623dc1f0$0200000a@bender> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3621.0 In-Reply-To: <3CD6B038.3E487B@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 > > But it's a standard WaveLAN/Orinico card, which is what the > wi driver > > is intended for? > > > > I never had to worry about any of this when I had the old > white/bronze > > 2mbit wavelan cards, but with silver and gold cards, its > been nothing > > but fun and games.... > > I suppose I can understand wanting to control the data rate > manually because you can, rather than just being happy it > works at the highest data rate... > > The only thing I could suggest would be to contact the driver > author directly and/or sign an NDA and get the programming > docs yourself. I'm pretty sure Julian could answer yes/no > questions about the card speed setttings. > > -- Terry Actually, the reason I wanted to control the data rate was so I could force it to run at 11mbit. I put the 11mbit card in, and it would still only run at 2mbit! I was unhappy I had faster cards, but they still wouldn't work beyond the 2mbit of the old ones I had. That's what got me playing with all these options... Windows XP on my laptop would say the speed its communicating at; but that's actually the speed XP on the laptop is trasmitting at, not receiving. Installing the Orinico client manager, I could see the packets my laptop was sending to the FreeBSD host (100% at 11mbit), and the packets the FreeBSD host was sending back to the laptop (100% at 2mbit). Playing with those options changed what speed it would transmit to me. Oh well. At least I found the magic options that needed to be set to make the card work at 11mbit. Oh, and btw. Leaving it on auto (wicontrol -t 3) it would actually drop from 11mbit to 5.5mbit as the quality dropped off when I was further out of range. So at least auto works too :) Perhaps when I have some spare time I can go look into the wi driver. And perhaps your right, firmware changes on the orinoco cards are the cause of this; I have flashed mine to 8.1 (or whatever the latest firmware is, 8.something). My white wavelan cards were originally firmware 1.0 when I got them :) Martin. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 6 17:33:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.airnet.com.au (mail.airnet.com.au [202.174.32.5]) by hub.freebsd.org (Postfix) with SMTP id BEDB737B401 for ; Mon, 6 May 2002 17:33:03 -0700 (PDT) Received: (qmail 25975 invoked from network); 7 May 2002 00:32:50 -0000 Received: from ppp126.ar1.adl1.airnet.com.au (HELO bender) (202.174.34.126) by mail.airnet.com.au with SMTP; 7 May 2002 00:32:50 -0000 From: "Martin Minkus" To: "'John Hay'" , "'Terry Lambert'" Cc: , Subject: RE: 802.11: WaveLAN/Orinoco Cards Date: Tue, 7 May 2002 10:01:53 +0930 Message-ID: <006601c1f55e$b74c81e0$0200000a@bender> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3621.0 In-Reply-To: <200205061816.g46IGDq60379@zibbi.icomtek.csir.co.za> 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 > > Martin Minkus wrote: > > > But it's a standard WaveLAN/Orinico card, which is what the wi > > > driver is intended for? > > > > > > I never had to worry about any of this when I had the old > > > white/bronze 2mbit wavelan cards, but with silver and gold cards, > > > its been nothing but fun and games.... > > > > I suppose I can understand wanting to control the data rate > manually > > because you can, rather than just being happy it works at > the highest > > data rate... > > > > The only thing I could suggest would be to contact the > driver author > > directly and/or sign an NDA and get the programming docs yourself. > > I'm pretty sure Julian could answer yes/no questions about the card > > speed setttings. > > > > Nothing as drastic as that. It is/was a bug and has been fixed: > > revision 1.100 > date: 2002/04/14 23:18:40; author: brooks; state: Exp; > lines: +15 -0 Fix tx-rate setting for Lucent cards. Oh, okay. silence:~> uname -a FreeBSD silence.diskiller.net 4.5-STABLE FreeBSD 4.5-STABLE #8: Fri Apr 5 21:43:06 CST 2002 diskiller@silence.diskiller.net:/usr/src/sys/compile/SILENCE i386 silence:~> April 5. So if I cvsup and make world/build a new kernel, I should have that fix then :) Thanks, Martin. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 6 18:38:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 5DBF037B404; Mon, 6 May 2002 18:38:33 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g471cVN03993; Mon, 6 May 2002 19:38:31 -0600 (MDT) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g471cSr34028; Mon, 6 May 2002 19:38:28 -0600 (MDT) (envelope-from imp@village.org) Date: Mon, 06 May 2002 19:38:14 -0600 (MDT) Message-Id: <20020506.193814.71562007.imp@village.org> To: diskiller@diskiller.net Cc: tlambert2@mindspring.com, freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: 802.11: WaveLAN/Orinoco Cards From: "M. Warner Losh" In-Reply-To: <005b01c1f4db$e3563f20$0200000a@bender> References: <3CD643F6.33680AA3@mindspring.com> <005b01c1f4db$e3563f20$0200000a@bender> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message: <005b01c1f4db$e3563f20$0200000a@bender> "Martin Minkus" writes: : But it's a standard WaveLAN/Orinico card, which is what the wi driver is : intended for? : : I never had to worry about any of this when I had the old white/bronze : 2mbit wavelan cards, but with silver and gold cards, its been nothing : but fun and games.... Yea. Terry is wrong here. Ignore what he says, for he knowest not what he talkest about. The wi driver might be getting some of them wrong, but it is impossible to say because you didn't include the version you were using (there was a bug releated to this fixed in the not too distant past). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 6 19:20:15 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 521D537B406; Mon, 6 May 2002 19:20:07 -0700 (PDT) Received: from pool0679.cvx21-bradley.dialup.earthlink.net ([209.179.194.169] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 174uaB-0001hu-00; Mon, 06 May 2002 19:20:04 -0700 Message-ID: <3CD739B6.BC412E4F@mindspring.com> Date: Mon, 06 May 2002 19:19:34 -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: Martin Minkus Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: 802.11: WaveLAN/Orinoco Cards References: <006501c1f55e$623dc1f0$0200000a@bender> 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 Martin Minkus wrote: > Perhaps when I have some spare time I can go look into the wi driver. > And perhaps your right, firmware changes on the orinoco cards are the > cause of this; I have flashed mine to 8.1 (or whatever the latest > firmware is, 8.something). My white wavelan cards were originally > firmware 1.0 when I got them :) Actually, it appears I'm wrong, and you just haven't read the message yet. Apparently there have been some commits which fix your problem for you (though they may be limited to -current). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 6 19:21:11 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 6E51337B405 for ; Mon, 6 May 2002 19:21:04 -0700 (PDT) Received: from there (eniac.foo.is [192.168.1.25]) by tesla.foo.is (Postfix) with SMTP id EEDA72744; Tue, 7 May 2002 02:20:57 +0000 (GMT) Content-Type: text/plain; charset="iso-8859-1" From: Baldur Gislason To: Garrett Wollman Subject: Re: Junior network hacker tasks... Date: Tue, 7 May 2002 02:20:49 +0000 X-Mailer: KMail [version 1.3.2] References: <200205062209.g46M99N8070646@khavrinen.lcs.mit.edu> In-Reply-To: <200205062209.g46M99N8070646@khavrinen.lcs.mit.edu> Cc: net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020507022058.EEDA72744@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 Also, there's a kernel option: # RANDOM_IP_ID causes the ID field in IP packets to be randomized # instead of incremented by 1 with each packet generated. This # option closes a minor information leak which allows remote # observers to determine the rate of packet generation on the # machine by watching the counter. options RANDOM_IP_ID On Monday 06 May 2002 22:09, you wrote: > Currently, FreeBSD's implementation of RFC 1323 uses the contents of > the `ticks' variable verbatim in the TCP timestamp options that it > generates. This is perhaps undesirable, in that it allows the system > at the other end to determine how long the system has been up. > (Current versions of `nmap' do this.) Also, there are ordered > comparisons done throughout the TCP implementation which will break > should `ticks' ever wrap around; with high values of `HZ' it is > possible for (the 32-bit truncation of) `ticks' to wrap over even > relatively small periods of time (e.g., five days for HZ=10000). > > The following would both be useful activities: > > 1) Change the RFC 1323 implementation to use ticks relative to the > time the socket was created. This is fairly easy to do and requires > changes to only a handful of lines of code. (Keep in mind that only > timestamps we send over the network ought to be so treated -- the > timestamps stored in the TCPCB are a separate issue.) For additional > confusion value, consider adding a random bias when each connection is > created. (TCP already bogusly depends on a maximum segment lifetime > of 30 seconds, so segments dallying in the network for days are > probably not a concern. The correct answer for the user who has set > HZ to 1000000 is ``don't do that, then'' -- but this probably ought to > be documented as a limitation.) > > 2) Examine the places where the TCP stack references `ticks' for other > reasons, and determine whether TCP would fail to operate correctly > should `ticks' wrap around. How likely are such failures? Would it > help if `ticks' (and derived values) were stored in a wider data type? > In some cases, the wrap-around interval is impossibly long with > respect to other timeouts, so there is not necessarily a problem in > all cases. > > -GAWollman > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 6 20:30:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id BFE9A37B403; Mon, 6 May 2002 20:30:07 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g473U5N04506; Mon, 6 May 2002 21:30:06 -0600 (MDT) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g473U3r34599; Mon, 6 May 2002 21:30:04 -0600 (MDT) (envelope-from imp@village.org) Date: Mon, 06 May 2002 21:29:45 -0600 (MDT) Message-Id: <20020506.212945.93008254.imp@village.org> To: tlambert2@mindspring.com Cc: diskiller@diskiller.net, freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: 802.11: WaveLAN/Orinoco Cards From: "M. Warner Losh" In-Reply-To: <3CD739B6.BC412E4F@mindspring.com> References: <006501c1f55e$623dc1f0$0200000a@bender> <3CD739B6.BC412E4F@mindspring.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message: <3CD739B6.BC412E4F@mindspring.com> Terry Lambert writes: : Martin Minkus wrote: : > Perhaps when I have some spare time I can go look into the wi driver. : > And perhaps your right, firmware changes on the orinoco cards are the : > cause of this; I have flashed mine to 8.1 (or whatever the latest : > firmware is, 8.something). My white wavelan cards were originally : > firmware 1.0 when I got them :) : : : Actually, it appears I'm wrong, and you just haven't read the : message yet. Apparently there have been some commits which : fix your problem for you (though they may be limited to -current). Nope. They have been MFC'd as of April 30th or so. The entire wi driver was back merged at that date. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 6 22: 9:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d118.as9.nwbl0.wi.voyager.net [169.207.132.246]) by hub.freebsd.org (Postfix) with ESMTP id 0C75337B404 for ; Mon, 6 May 2002 22:09:19 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.3/8.12.3) with ESMTP id g475AHUm063582; Tue, 7 May 2002 00:10:17 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.3/8.12.3/Submit) with ESMTP id g475AAlF063579; Tue, 7 May 2002 00:10:12 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Tue, 7 May 2002 00:10:09 -0500 (CDT) From: Mike Silbersack To: Garrett Wollman Cc: net@freebsd.org Subject: Re: Junior network hacker tasks... In-Reply-To: <200205062253.g46MrWiY071722@khavrinen.lcs.mit.edu> Message-ID: <20020507000816.L62342-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 6 May 2002, Garrett Wollman wrote: > < said: > > > Is doing this wise? I have this nagging feeling that randomizing (or > > zeroing on each new connection) the timestamp would degrade its usefulness > > for PAWS checks and the like. (Don't ask me how, I haven't thought it > > through fully.) > > I don't think so, because the timestamps, as currently specified, are > only meaningful within the context of a single connection. See > sections 1.2, 4.3, and 4.2 of RFC 1323. The PAWS mechanism requires > only that timestamps used by each connection be monotone increasing > with respect to Sequence Number Arithmetic. RFC 1323 does require > (section 4.2.2) that the clock be between 1 ms and 1 s in period, > which I think we already violate on some platforms, although not > seriously; there probably should be a pre-computed (global) scaling > factor as well. > > -GAWollman I looked over both our and Linux's tcp stack to double-check, and it appears that my memory was faulty. You are correct, no PAWS checks are done during TIME_WAIT recycling. Initializing to zero is probably the best idea; getting fancy with random starts doesn't really help anything. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 6 22:57:56 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 5C3CD37B407 for ; Mon, 6 May 2002 22:57:53 -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 <20020507055753.UTE5896.rwcrmhc53.attbi.com@blossom.cjclark.org>; Tue, 7 May 2002 05:57:53 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g475vqX89832; Mon, 6 May 2002 22:57:52 -0700 (PDT) (envelope-from cjc) Date: Mon, 6 May 2002 22:57:52 -0700 From: "Crist J. Clark" To: Baldur Gislason Cc: Garrett Wollman , net@FreeBSD.ORG Subject: Re: Junior network hacker tasks... Message-ID: <20020506225752.I89339@blossom.cjclark.org> References: <200205062209.g46M99N8070646@khavrinen.lcs.mit.edu> <20020507022058.EEDA72744@tesla.foo.is> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020507022058.EEDA72744@tesla.foo.is>; from baldur@foo.is on Tue, May 07, 2002 at 02:20:49AM +0000 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, May 07, 2002 at 02:20:49AM +0000, Baldur Gislason wrote: > Also, there's a kernel option: > # RANDOM_IP_ID causes the ID field in IP packets to be randomized > # instead of incremented by 1 with each packet generated. This > # option closes a minor information leak which allows remote > # observers to determine the rate of packet generation on the > # machine by watching the counter. > options RANDOM_IP_ID ...which has absolutely nothing to do with this thread. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 6 23:34:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id EAD1F37B403; Mon, 6 May 2002 23:34:10 -0700 (PDT) Received: from pool0102.cvx21-bradley.dialup.earthlink.net ([209.179.192.102] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 174yXq-0002OY-00; Mon, 06 May 2002 23:33:54 -0700 Message-ID: <3CD77534.4975CB62@mindspring.com> Date: Mon, 06 May 2002 23:33:24 -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: "M. Warner Losh" Cc: diskiller@diskiller.net, freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: 802.11: WaveLAN/Orinoco Cards References: <006501c1f55e$623dc1f0$0200000a@bender> <3CD739B6.BC412E4F@mindspring.com> <20020506.212945.93008254.imp@village.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 "M. Warner Losh" wrote: > : Actually, it appears I'm wrong, and you just haven't read the > : message yet. Apparently there have been some commits which > : fix your problem for you (though they may be limited to -current). > > Nope. They have been MFC'd as of April 30th or so. The entire wi > driver was back merged at that date. THanks for the clarification... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue May 7 9: 8:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from cedar.ie.tusur.ru (cedar.ie.tusur.ru [212.192.122.23]) by hub.freebsd.org (Postfix) with ESMTP id C968C37B403 for ; Tue, 7 May 2002 09:07:54 -0700 (PDT) Received: from rainbow.ie.tusur.ru (rainbow.ie.tusur.ru [212.192.122.75]) by cedar.ie.tusur.ru (8.11.6/8.11.6) with ESMTP id g47G2qj45251 for ; Tue, 7 May 2002 23:02:53 +0700 (TSD) (envelope-from pg@rainbow.ie.tusur.ru) Received: (from pg@localhost) by rainbow.ie.tusur.ru (8.9.3/Cedar1_MH) id XAA69974 for freebsd-net@freebsd.org; Tue, 7 May 2002 23:02:52 +0700 (TSD) (envelope-from pg) Date: Tue, 7 May 2002 23:02:51 +0700 From: Pavel Gubin To: freebsd-net@freebsd.org Subject: netgraph and ipx tunneling Message-ID: <20020507230250.C69343@ie.tusur.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: TUCSR, Industrial Electronics dept Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, I have the following network setup: Srv1 Srv2 [nw3.12]--ipx/802.2--[freebsd4.4]--ip--[freebsd4.4]--ipx/eII--[clients] 0x2 net=0x23 fxp1 IP1 IP2 xl0 net=0x56 I trying to setup ipx tunnel between Netware 3.12 and "clients" in remote intranet in such a way: Srv1: - kernel with net options: INET,IPFIREWALL,IPFIREWALL_FORWARD,IPDIVERT,IPX,IPXIP,DUMMYNET - net.ipx.ipx.ipxforwarding=1 - module if_ef loaded as KLD, compiled with options ETHER_II, ETHER_8022 - startup: ifconfig fxp1f2 ipx 0x23 ngctl mkpeer iface dummy ipx ngctl msg ng0: broadcast ngctl mkpeer ng0: ksocket ipx inet/dgram/udp ngctl name ng0:ipx ipxtun ngctl msg ipxtun: bind inet/IP1:4444 ngctl msg ipxtun: connect inet/IP2:4444 ifconfig ng0 ipx 0x2356.0x2323 IPXrouted -s Srv2: - kernel with net options: INET,IPFIREWALL,IPDIVERT,IPX,DUMMYNET - net.ipx.ipx.ipxforwarding=1 - module if_ef not loaded - startup: ifconfig xl0 ipx 0x56 ngctl mkpeer iface dummy ipx ngctl msg ng0: broadcast ngctl mkpeer ng0: ksocket ipx inet/dgram/udp ngctl name ng0:ipx ipxtun ngctl msg ipxtun: bind inet/IP2:4444 ngctl msg ipxtun: connect inet/IP1:4444 ifconfig ng0 ipx 0x2356.0x3838 IPXrouted -s Then: 1) nw3.12's DISPLAY NETWORKS result: 00000002 0/1 00000023 0/1 0000056 2/2 0002356 1/1 2) Srv1's netstat -rnf ipx: 2.* 23.30840e17ae UG fxp1f2 ^^^^^^^^^^-----------(nw3.12's MAC) 23.* 23.60b01a8ec2 U fxp1f2 56.* 2356.3838 UG ng0 2356.* 2356.2323 U ng0 3) Srv2's netstat -rnf ipx: 2.* 2356.2323 UG ng0 23.* 2356.2323 UG ng0 56.* 56.102dd9382 U xl0 2356.* 2356.3838 U ng0 Seems that all OK, but clients did not see the Netware server :( Where am I wrong? -- Pavel Gubin TUSC&R / Industrial Electronics dept / System Administrator 2:5005/14@fidonet / Phone +7-3822-423067 / ICQ 28835566 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue May 7 16:15:45 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 6B3F537B408; Tue, 7 May 2002 16:15:36 -0700 (PDT) Received: from there (eniac.foo.is [192.168.1.25]) by tesla.foo.is (Postfix) with SMTP id 8B55C2744; Tue, 7 May 2002 23:15:29 +0000 (GMT) Content-Type: text/plain; charset="iso-8859-1" From: Baldur Gislason To: Tom Limoncelli Subject: Re: ipf vs. ipfw Date: Tue, 7 May 2002 23:15:17 +0000 X-Mailer: KMail [version 1.3.2] References: <3CD8558E.2FA68C36@lumeta.com> In-Reply-To: <3CD8558E.2FA68C36@lumeta.com> Cc: freebsd-security@freebsd.org, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020507231529.8B55C2744@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 ipfw is in no way related to the linux firewalls (ipfwadm, ipchains or iptables). It is a specially designed firewall for FreeBSD. It isn't dependent on ipf, it has it's own in-kernel mechanism. It has a totally different syntax. Why FreeBSD has both I can't answer, ipfw and ipf each have their own advantages over each other. In my experience, ipfw is easier to work with, but it's also limited in some ways. Ipf tends to have a more complex ruleset, and more stateful functionality (ipfw can do stateful filtering but ipf has more customisable state keeping rules IIRC), however ipfw does have the ability to apply rules by uid's if you're doing a firewall for the local machine, and it does have a packet/byte counter for each individual rule. I'm not sure how this is with ipf as I haven't used is as much as I have used ipfw. Baldur On Tuesday 07 May 2002 22:30, you wrote: > I use ipf, and recently some people have asked me about ipfw that I > couldn't answer. Hopefully people on this list can enlighten me. > > Are ipf and ipfw different interfaces to the same in-kernel filtering > mechanism? It doesn't look like it is, but I'd like that confirmed. > > Is ipfw related at all to the Linux ipfw? The syntax looks the same, > but the man page doesn't mention Linux. > > Why does FreeBSD have both? Is it because ipf is generic (ported to > Solaris, IRIX, OpenBSD, etc) and ipfw is specifically designed for > FreeBSD? > > Thanks in advance! > --tal > > P.S. I'm collecting data here: > http://whatexit.org/tal/mywritings/freefilters.html > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue May 7 17:36: 6 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 1CA4737B404; Tue, 7 May 2002 17:35:43 -0700 (PDT) Received: from gateway.posi.net ([12.236.90.177]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020508003542.MOOY7420.rwcrmhc53.attbi.com@gateway.posi.net>; Wed, 8 May 2002 00:35:42 +0000 Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.11.6/8.11.6) with ESMTP id g480ZZW28425; Tue, 7 May 2002 17:35:35 -0700 (PDT) (envelope-from kbyanc@posi.net) X-Authentication-Warning: gateway.posi.net: kbyanc owned process doing -bs Date: Tue, 7 May 2002 17:35:34 -0700 (PDT) From: Kelly Yancey To: freebsd-stable@freebsd.org Cc: freebsd-tokenring@freebsd.org, Subject: Call for testers Message-ID: <20020507171815.H28397-200000@gateway.posi.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1423277081-1020818134=:28397" 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-1423277081-1020818134=:28397 Content-Type: TEXT/PLAIN; charset=US-ASCII I am looking for testers for the attached patch in hopes of MFC'ing this bug-fix from -current to -stable in time for 4.6-RELEASE. The bug being addressed is that interface's with names longer than 6 characters often overflow the sockaddr_dl data structure's buffer for holding them (specifically, 7 or more characters for the interface name plus the 6 bytes for ethernet or token ring hardware addresses exceeds the 12 byte sdl_data field that is to hold them). The manifestation of this bug is that the iso 802.5 source routing control field is overwritten with part of the interface's hardware address (and vice-a-versa). The fix committed to -current is the same as that in the attached patch. Both give the storage previously reserved for 802.5 source routing information to the sdl_data field so it may be used to hold longer interface names or hardware addresses. In the case of token-ring, source routing information is stored in the sdl_data field now, but at the same offset as it used to be in the structure, so there is effectively no change. So the overall effect is that token-ring interface names still may not exceed 6 characters in length. However, for all other interfaces, there is plenty of room allotted for the interface name and hardware address (46 bytes now as compared to 12) thereby averting the overflow. In addition, since the structure offsets did not change nor did the size of the sockaddr_dl structure itself, I believe there should be no imcompatibility with binary-only network drivers. However, I do not have access to any token-ring hardware so I cannot be 100% sure that I didn't break 802.5 source routing on such devices. Therefor, I would be most grateful if anyone with token ring hardware could please apply the attached patches and report any successes for failures. Thanks, Kelly --0-1423277081-1020818134=:28397 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="sdl_data-overflow4.diff" Content-Transfer-Encoding: BASE64 Content-ID: <20020507173534.P28397@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-1423277081-1020818134=:28397-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue May 7 18: 9:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.deltanet.com (mail.deltanet.com [216.237.144.132]) by hub.freebsd.org (Postfix) with ESMTP id 2AE9A37B400 for ; Tue, 7 May 2002 18:09:18 -0700 (PDT) Received: from mammoth.hb.frenchfries.net (da001d1280.lax-ca.osd.concentric.net [208.36.180.5]) by mail.deltanet.com (8.11.6/8.11.6) with ESMTP id g480naP18151 for ; Tue, 7 May 2002 17:49:37 -0700 Received: from localhost (pherman@localhost) by mammoth.hb.frenchfries.net (8.12.3/8.12.3/Submit) with ESMTP id g4811Gp5000716 for ; Tue, 7 May 2002 18:01:16 -0700 (PDT) X-Authentication-Warning: mammoth.hb.frenchfries.net: pherman owned process doing -bs Date: Tue, 7 May 2002 17:55:55 -0700 (PDT) From: Paul Herman X-X-Sender: pherman@mammoth.hb.frenchfries.net To: freebsd-net@freebsd.org Subject: Wireless NIC only works in promiscuous mode Message-ID: <20020507173608.R150-100000@mammoth.hb.frenchfries.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I've got a Linksys WMP11 "Instant Wireless" PCI card running on 4.6-PRERELEASE: wi0: mem 0xf4200000-0xf4200fff irq 3 at device 11.0 on pci1 wi0: 802.11 address: 00:06:25:a7:47:93 wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI) wi0: Intersil Firmware: Primary 1.00.05, Station 1.03.04 I've got it working (talking to a MacOSX machine, ARP, ping, FTP, ssh, etc. all work), but it only works when the interface is in promiscuous mode! i.e. I have to run tcpdump, and "tcpdump -i wi0" makes it work, and "tcpdump -i wi0 -p" doesn't. Is this an issue with the driver, or is it cockpit error on my part? -Paul. bash# ifconfig wi0 inet 192.168.1.1/24 ssid testnet channel 2 bash# ifconfig wi0 wi0: flags=8943 mtu 1500 inet6 fe80::206:25ff:fea7:4793%wi0 prefixlen 64 scopeid 0x1 inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 ether 00:06:25:a7:47:93 media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps ) status: associated ssid testnet 1:testnet stationname mammoth channel 2 authmode OPEN powersavemode OFF powersavesleep 100 wepmode OFF weptxkey 1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue May 7 19:24:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from pcp-2.ihug.co.nz (pcp-2.ihug.co.nz [203.109.252.66]) by hub.freebsd.org (Postfix) with ESMTP id 1791737B405 for ; Tue, 7 May 2002 19:24:31 -0700 (PDT) Received: from 203-173-242-48.adsl.ihug.co.nz (ihug.co.nz) [203.173.242.48] by pcp-2.ihug.co.nz with esmtp (Exim 3.22 #1 (Debian)) id 175H81-0004MI-00; Wed, 08 May 2002 14:24:29 +1200 Message-ID: <3CD88C72.8030203@ihug.co.nz> Date: Wed, 08 May 2002 14:24:50 +1200 From: Matthew Luckie User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc1) Gecko/20020428 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: log_arp_movements Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Any chance that the following patch could be MFC'd? http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/if_ether.c.diff?r1=1.80&r2=1.81 The format string passed to log has changed slightly in the previous 8 months, but other than that it looks reasonably straight forward. -- Matthew Luckie kluckie@ihug.co.nz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 8 2:16:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from cairo.anu.edu.au (cairo.anu.edu.au [150.203.224.11]) by hub.freebsd.org (Postfix) with ESMTP id 85C5237B408; Wed, 8 May 2002 02:16:16 -0700 (PDT) Received: from cairo.anu.edu.au (localhost [127.0.0.1]) by cairo.anu.edu.au (8.12.0/8.12.0) with ESMTP id g489GD3g019357; Wed, 8 May 2002 19:16:13 +1000 (EST) Received: (from avalon@localhost) by cairo.anu.edu.au (8.12.0/8.12.0.Beta16) id g489GDec019355; Wed, 8 May 2002 19:16:13 +1000 (EST) From: Darren Reed Message-Id: <200205080916.g489GDec019355@cairo.anu.edu.au> Subject: Re: ipf vs. ipfw To: baldur@foo.is (Baldur Gislason) Date: Wed, 8 May 2002 19:16:13 +1000 (Australia/NSW) Cc: tal@lumeta.com (Tom Limoncelli), freebsd-security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG In-Reply-To: <20020507231529.8B55C2744@tesla.foo.is> from "Baldur Gislason" at May 07, 2002 11:15:17 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In some mail from Baldur Gislason, sie said: > > ipfw is in no way related to the linux firewalls (ipfwadm, ipchains or > iptables). It is a specially designed firewall for FreeBSD. It isn't > dependent on ipf, it has it's own in-kernel mechanism. It has a totally > different syntax. Why FreeBSD has both I can't answer, ipfw and ipf each have > their own advantages over each other. In my experience, ipfw is easier to > work with, but it's also limited in some ways. Ipf tends to have a more > complex ruleset, and more stateful functionality (ipfw can do stateful > filtering but ipf has more customisable state keeping rules IIRC), however > ipfw does have the ability to apply rules by uid's if you're doing a firewall > for the local machine, and it does have a packet/byte counter for each > individual rule. I'm not sure how this is with ipf as I haven't used is as > much as I have used ipfw. ipf has a completely separate set of rules you can use for accounting and is minus any os-specific hacks (such as uid filtering) ipfw does share its roots with the linux ipfw but linux long ago dropped its one and the freebsd one is now much different. ipf used to be more "leading edge" than any of the others and hence offered more features and a bigger coolness factor but I've been slack for the last year or two on that front. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 8 6:10:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtp.hexanet.fr (smtp.hexanet.fr [81.23.32.141]) by hub.freebsd.org (Postfix) with ESMTP id 60F9637B409; Wed, 8 May 2002 06:10:19 -0700 (PDT) Received: from speedfreak.rural (speedfreak.hexanet.fr [81.23.32.34]) by smtp.hexanet.fr (8.9.3/8.9.3) with ESMTP id PAA83828; Wed, 8 May 2002 15:10:17 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Received: from speedfreak (locahost.rural [127.0.0.1]) by speedfreak.rural (8.11.6/8.11.6) with SMTP id g48DAF501466; Wed, 8 May 2002 15:10:16 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Wed, 8 May 2002 15:10:15 +0200 From: Christophe Prevotaux To: freebsd-net@freebsd.org Cc: freebsd-hardware@freebsd.org Subject: UDLR Message-Id: <20020508151015.1a1c392f.c.prevotaux@hexanet.fr> Organization: HEXANET X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-portbld-freebsd4.5) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I have once asked if someone would be interested in implementing UDLR and DVMRP and include it in FreeBSD ? Julian Elischer mentioned it would be fairly trivial to implement as a node in Netgraph. However I am no programmer. I was wondering if no one had interest in UDLR ? I understand that today's broadband access do not require these unidirectional links, but I can't believe no one needs this, since they are also plenty of other use for it apart from the fact it can be used for unidirectional link (one way internet access (uplink is done thru a modem or a different kind of internet access link)) If someone is interested in develloping this, there is some code source available (it is FreeBSD Release 2.2.x. based and has not been maintained for a long time). Receivers boards ================ DVB-S PCI adapter drivers are also needed for devices from any of these manufacturers http://www.coship.com/English/products/cdvbany2010s.htm http://www.broadlogic.com http://www.pentamedia.com http://www.twinhan.com.tw who might be ready to lend or give out hardware in order to help devellopement of these drivers. Uplink boards ============= These boards must be able to: - Transmit IP packet over DVB/MPEG 2 transport stream - Variable maximum data rate determined by external clock generator, transparent for reception cards - ISA Bus As of today I have not found (yet) transmit (uplink) boards manufacturer As for uplink boards the devellopement of such drivers are to be a problem since it is very unlikely that anyone as a personal space segment on a DVB capable satellite and the necessary hardware However if anyone has ideas on how to build a test cheap unit for uplink and downlink testing locally , please let me know. Also since Bill Fenner is both part of the UDLR IETF BOARD and member of the Mbone FreeBSD Team, we have a great source of internal knowledge in this protocol etc...(In the event that Bill agrees to help (of course)) http://people.freebsd.org/~fenner/ I have contacted the author of the RFC for UDLR Emmanuel Duros but as of now it is to no avail since he has not answered my email (it has been several months) Here are some pointers to some available literature and source code: What is UDLR (Short introduction) ================================= http://www.actconferences.com/sif2002/abstract/udlr.htm RFCs , Drafts and Charter ========================= http://www.ietf.org/html.charters/udlr-charter.html http://www.ietf.org/internet-drafts/draft-ietf-udlr-pppoe-00.txt http://www.ietf.org/internet-drafts/draft-ietf-udlr-multicast-issues-00.txt http://www.ietf.org/internet-drafts/draft-ietf-udlr-security-00.txt http://www.ietf.org/internet-drafts/draft-ietf-udlr-dvmrp-conf-02.txt http://www.ietf.org/rfc/rfc3077.txt http://www.ietf.org/rfc/rfc1075.txt Source code =========== http://www-sop.inria.fr/rodeo/personnel/eduros/manu.html -- -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 79 08 02 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 8 8:56:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 6335A37B404; Wed, 8 May 2002 08:56:39 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.3/8.12.3) with ESMTP id g48FuZEN084027; Wed, 8 May 2002 11:56:35 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.3/8.12.3/Submit) id g48FuY0q084024; Wed, 8 May 2002 11:56:34 -0400 (EDT) Date: Wed, 8 May 2002 11:56:34 -0400 (EDT) From: Garrett Wollman Message-Id: <200205081556.g48FuY0q084024@khavrinen.lcs.mit.edu> To: Darren Reed Cc: freebsd-security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: ipf vs. ipfw In-Reply-To: <200205080916.g489GDec019355@cairo.anu.edu.au> References: <20020507231529.8B55C2744@tesla.foo.is> <200205080916.g489GDec019355@cairo.anu.edu.au> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > ipfw does share its roots with the linux ipfw but linux long ago dropped > its one and the freebsd one is now much different. It is possible that the old Lignux `ipfw' was based on FreeBSD's; not the other way around. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 8 10:18:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from exgw2.lumeta.com (exgw2.lumeta.com [65.198.68.66]) by hub.freebsd.org (Postfix) with ESMTP id 5823237B409; Wed, 8 May 2002 10:18:22 -0700 (PDT) Received: from lucy.corp.lumeta.com (h65-198-68-133.lumeta.com [65.198.68.133]) by exgw2.lumeta.com (Postfix) with ESMTP id 89157373835; Wed, 8 May 2002 13:18:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucy.corp.lumeta.com (Postfix) with ESMTP id 7E78C10842; Wed, 8 May 2002 13:18:16 -0400 (EDT) Received: from lumeta.com (tal.corp.lumeta.com [65.198.68.200]) by lucy.corp.lumeta.com (Postfix) with ESMTP id A10E010841; Wed, 8 May 2002 13:18:07 -0400 (EDT) Message-ID: <3CD95E0F.A3E7398C@lumeta.com> Date: Wed, 08 May 2002 13:19:11 -0400 From: Tom Limoncelli Organization: Lumeta Corp X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Cc: Darren Reed Subject: Re: ipf vs. ipfw References: <200205080916.g489GDec019355@cairo.anu.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thanks to everyone that answered my questions. As in true Usenet tradition, if you want the full story, post a message with a lot of incorrect statements. I got much better results than the carefully thought out queries that I had sent to various people. :-) I've updated my page http://whatexit.org/tal/mywritings/freefilters.html --Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 8 11:30:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by hub.freebsd.org (Postfix) with ESMTP id 31F4737B425; Wed, 8 May 2002 11:29:51 -0700 (PDT) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.3/8.11.6) with ESMTP id g48IN4kx068826; Wed, 8 May 2002 14:23:05 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200205081823.g48IN4kx068826@nic-naa.net> To: Christophe Prevotaux Cc: freebsd-net@FreeBSD.ORG, freebsd-hardware@FreeBSD.ORG, Emmanuel.Duros@sophia.inria.fr Subject: Re: UDLR In-Reply-To: Your message of "Wed, 08 May 2002 15:10:15 +0200." <20020508151015.1a1c392f.c.prevotaux@hexanet.fr> Date: Wed, 08 May 2002 14:23:04 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Howdy Christophe, The directory ftp-sop.inria.fr/rodeo/eduros/pub/dvd, pointed to in http://www-sop.inria.fr/rodeo/personnel/eduros/index-dvb.html does not exist. Was I supposed to look somewhere else? Eric To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 8 12:15: 9 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 55C2137B400 for ; Wed, 8 May 2002 12:15:03 -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 MAA25047 for ; Wed, 8 May 2002 12:02:36 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g48J2aZ24545 for freebsd-net@freebsd.org; Wed, 8 May 2002 12:02:36 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200205081902.g48J2aZ24545@arch20m.dellroad.org> Subject: Transmitting packets when not IFF_UP To: freebsd-net@freebsd.org Date: Wed, 8 May 2002 12:02:36 -0700 (PDT) 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 Several people using netgraph for bridging, PPPoE, or whatever have encountered the problem where transmitting a packet out an interface that is not marked IFF_UP causes a panic. This is because many drivers were written with the assumption that this would never happen. To fix this once and for all I'd like to commit the patch below. Comments and reviews warmly appreciated... Thanks, -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com Index: sys/net/if_ethersubr.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_ethersubr.c,v retrieving revision 1.110 diff -u -U8 -r1.110 if_ethersubr.c --- if_ethersubr.c 4 Apr 2002 05:42:09 -0000 1.110 +++ if_ethersubr.c 8 May 2002 19:01:56 -0000 @@ -372,16 +372,22 @@ */ int ether_output_frame(ifp, m) struct ifnet *ifp; struct mbuf *m; { int error = 0; + /* Don't send packet if the interface is not up */ + if ((ifp->if_flags & (IFF_UP|IFF_RUNNING)) != (IFF_UP|IFF_RUNNING)) { + m_freem(m); + return (ENETDOWN); + } + if (BDG_ACTIVE(ifp) ) { struct ether_header *eh; /* a ptr suffices */ m->m_pkthdr.rcvif = NULL; eh = mtod(m, struct ether_header *); m_adj(m, ETHER_HDR_LEN); m = bdg_forward_ptr(m, eh, ifp); if (m != NULL) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 8 13:27:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from senator.nodewarrior.org (senator.nodewarrior.org [216.243.168.27]) by hub.freebsd.org (Postfix) with ESMTP id D5DBC37BB54 for ; Wed, 8 May 2002 13:26:45 -0700 (PDT) Received: from senator.nodewarrior.org.nodewarrior.org (senator [216.243.168.27]) by senator.nodewarrior.org (Postfix) with ESMTP id 0EE1021C71 for ; Wed, 8 May 2002 15:26:43 -0500 (CDT) From: Dan Debertin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15577.35331.9375.80334@senator.nodewarrior.org> Date: Wed, 8 May 2002 15:26:42 -0500 To: freebsd-net@freebsd.org Subject: gx not recognizing PRO/1000 interfaces X-Mailer: VM 7.03 under Emacs 21.2.1 Microsoft: Where the service packs are larger than the original releases. 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 new Dell PowerEdge 1650 with dual onboard Intel PRO/1000 interfaces. I can get it to probe under the em driver, but not gx or wx (which I understand is deprecated, but I figured it was worth a shot). I have tried both GENERIC with gx added, as well as a slimmed-down kernel with only miibus and gx. pci1: (vendor=0x8086, dev=0x1008) at 2.0 irq 7 pci1: (vendor=0x8086, dev=0x1008) at 4.0 irq 5 Is gx supposed to work with these interfaces? (As an aside, if anyone wants to comment on the relative merits of em vs. gx, that would be great). Dan -- airboss@nodewarrior.org www.nodewarrior.org ignorami: n: The art of folding problem users into representational shapes. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 8 14:41:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from apollo.sitaranetworks.com (apollo.sitaranetworks.com [199.103.141.105]) by hub.freebsd.org (Postfix) with ESMTP id A748B37B40B for ; Wed, 8 May 2002 14:41:24 -0700 (PDT) Received: from rios.sitaranetworks.com (rios.sitaranetworks.com [199.103.141.78]) by apollo.sitaranetworks.com (8.10.2+Sun/8.9.3) with ESMTP id g48LfK326269; Wed, 8 May 2002 17:41:20 -0400 (EDT) Received: by rios.sitaranetworks.com with Internet Mail Service (5.5.2653.19) id <27RXKRTL>; Wed, 8 May 2002 17:41:33 -0400 Message-ID: <31269226357BD211979E00A0C9866DAB03755DEC@rios.sitaranetworks.com> From: Jim McGrath To: "'Dan Debertin'" , freebsd-net@FreeBSD.ORG Subject: RE: gx not recognizing PRO/1000 interfaces Date: Wed, 8 May 2002 17:41:32 -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 The wx driver only supports through the 82543 chipset. It is trivial to add 82544 support. I suppose it was not done because it has been deprecated. I'm not sure of the state of the gx driver. It possibly only supports through the 82543 also. The last I heard, someone was having trouble with promiscious mode in the em driver. I don't know if that has been resolved. Jim -----Original Message----- From: Dan Debertin [mailto:airboss@nodewarrior.org] Sent: Wednesday, May 08, 2002 4:27 PM To: freebsd-net@FreeBSD.ORG Subject: gx not recognizing PRO/1000 interfaces I have a new Dell PowerEdge 1650 with dual onboard Intel PRO/1000 interfaces. I can get it to probe under the em driver, but not gx or wx (which I understand is deprecated, but I figured it was worth a shot). I have tried both GENERIC with gx added, as well as a slimmed-down kernel with only miibus and gx. pci1: (vendor=0x8086, dev=0x1008) at 2.0 irq 7 pci1: (vendor=0x8086, dev=0x1008) at 4.0 irq 5 Is gx supposed to work with these interfaces? (As an aside, if anyone wants to comment on the relative merits of em vs. gx, that would be great). Dan -- airboss@nodewarrior.org www.nodewarrior.org ignorami: n: The art of folding problem users into representational shapes. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 8 14:54:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from senator.nodewarrior.org (senator.nodewarrior.org [216.243.168.27]) by hub.freebsd.org (Postfix) with ESMTP id 781B837B407 for ; Wed, 8 May 2002 14:54:49 -0700 (PDT) Received: from senator.nodewarrior.org.nodewarrior.org (senator [216.243.168.27]) by senator.nodewarrior.org (Postfix) with ESMTP id 8C1F121C71 for ; Wed, 8 May 2002 16:54:47 -0500 (CDT) From: Dan Debertin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15577.40615.177779.7670@senator.nodewarrior.org> Date: Wed, 8 May 2002 16:54:47 -0500 To: freebsd-net@freebsd.org Subject: RE: gx not recognizing PRO/1000 interfaces In-Reply-To: <31269226357BD211979E00A0C9866DAB03755DEC@rios.sitaranetworks.com> References: <31269226357BD211979E00A0C9866DAB03755DEC@rios.sitaranetworks.com> X-Mailer: VM 7.03 under Emacs 21.2.1 X-Meat: Lobster 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 Jim McGrath writes: > The last I heard, someone was having trouble with > promiscious mode in the em driver. I don't know if that has been resolved. At least in 4.5-RELEASE, em appears to be full functional. PROMISC works fine, though I can't find the original post that described what the trouble was. Dan -- airboss@nodewarrior.org www.nodewarrior.org ignorami: n: The art of folding problem users into representational shapes. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 8 15:25:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from cairo.anu.edu.au (cairo.anu.edu.au [150.203.224.11]) by hub.freebsd.org (Postfix) with ESMTP id 00B6F37B400; Wed, 8 May 2002 15:25:52 -0700 (PDT) Received: from cairo.anu.edu.au (localhost [127.0.0.1]) by cairo.anu.edu.au (8.12.0/8.12.0) with ESMTP id g48MPo3g023731; Thu, 9 May 2002 08:25:50 +1000 (EST) Received: (from avalon@localhost) by cairo.anu.edu.au (8.12.0/8.12.0.Beta16) id g48MPnML023729; Thu, 9 May 2002 08:25:49 +1000 (EST) From: Darren Reed Message-Id: <200205082225.g48MPnML023729@cairo.anu.edu.au> Subject: Re: ipf vs. ipfw To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Date: Thu, 9 May 2002 08:25:49 +1000 (Australia/NSW) Cc: freebsd-security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG In-Reply-To: <200205081556.g48FuY0q084024@khavrinen.lcs.mit.edu> from "Garrett Wollman" at May 08, 2002 11:56:34 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In some mail from Garrett Wollman, sie said: > > < said: > > > ipfw does share its roots with the linux ipfw but linux long ago dropped > > its one and the freebsd one is now much different. > > It is possible that the old Lignux `ipfw' was based on FreeBSD's; not > the other way around. You might be right about that as I believe there was attribution in Linux to FreeBSD. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 8 15:34: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from cairo.anu.edu.au (cairo.anu.edu.au [150.203.224.11]) by hub.freebsd.org (Postfix) with ESMTP id 457A437B400; Wed, 8 May 2002 15:34:01 -0700 (PDT) Received: from cairo.anu.edu.au (localhost [127.0.0.1]) by cairo.anu.edu.au (8.12.0/8.12.0) with ESMTP id g48MXv3g024458; Thu, 9 May 2002 08:33:57 +1000 (EST) Received: (from avalon@localhost) by cairo.anu.edu.au (8.12.0/8.12.0.Beta16) id g48MXtIK024453; Thu, 9 May 2002 08:33:55 +1000 (EST) From: Darren Reed Message-Id: <200205082233.g48MXtIK024453@cairo.anu.edu.au> Subject: Re: ipf vs. ipfw To: tal@lumeta.com (Tom Limoncelli) Date: Thu, 9 May 2002 08:33:55 +1000 (Australia/NSW) Cc: freebsd-security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG In-Reply-To: <3CD95E0F.A3E7398C@lumeta.com> from "Tom Limoncelli" at May 08, 2002 01:19:11 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In some mail from Tom Limoncelli, sie said: > > Thanks to everyone that answered my questions. As in true Usenet > tradition, if you want the full story, post a message with a lot of > incorrect statements. I got much better results than the carefully thought > out queries that I had sent to various people. :-) > > I've updated my page > http://whatexit.org/tal/mywritings/freefilters.html The line entry for pf is wrong. It is defaintely not a superset of IPFilter or ipfw or any of the other free packet filtering systems. It should simply say pf includes the listed features. You also do not mention SunScreen. Version 3.1(Lite) came with Solaris8, 3.2 will be bundled with Solaris9 (don't know if this is the Lite version or not). Don't know if anyone actually uses it, either. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 8 19: 5: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from magellan.palisadesys.com (magellan.palisadesys.com [192.188.162.211]) by hub.freebsd.org (Postfix) with ESMTP id 07B0937B409 for ; Wed, 8 May 2002 19:05:02 -0700 (PDT) Received: from spencer (desmdslgw5poola64.desm.uswest.net [63.230.48.64]) (authenticated (0 bits)) by magellan.palisadesys.com (8.11.6/8.11.6) with ESMTP id g4924nI30114 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Wed, 8 May 2002 21:04:56 -0500 From: "Guy Helmer" To: "'Dan Debertin'" , Subject: RE: gx not recognizing PRO/1000 interfaces Date: Wed, 8 May 2002 21:04:49 -0500 Organization: Palisade Systems, Inc Message-ID: <001701c1f6fd$eaf81450$0200000a@spencer> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <15577.40615.177779.7670@senator.nodewarrior.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 Dan Debertin wrote: > Jim McGrath writes: > > The last I heard, someone was having trouble with > > promiscious mode in the em driver. I don't know if that > has been resolved. > > At least in 4.5-RELEASE, em appears to be full functional. PROMISC > works fine, though I can't find the original post that described what > the trouble was. I found that one of the two drivers (gx or wx, I would have to look back at my notes to see which) would not go into promiscuous mode. I found that the other of those two drivers would seemingly lock up when I was moving files through it at a full load (on a 100Mbps half-duplex network). I have seen neither of these problems with the em driver (thank goodness!). Guy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 8 19: 9:32 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 B1BB437B400 for ; Wed, 8 May 2002 19:09:25 -0700 (PDT) Received: from hubble.home.ben.com (hubble.home.ben.com [172.17.42.2]) by saturn.home.ben.com (8.12.3/8.12.3) with ESMTP id g4929P8n008745 for ; Wed, 8 May 2002 19:09:25 -0700 (PDT) Received: (from bjj@localhost) by hubble.home.ben.com (8.11.3/8.11.1) id g47AchL00352 for freebsd-net@freebsd.org; Tue, 7 May 2002 03:38:43 -0700 (PDT) (envelope-from bjj) Date: Tue, 7 May 2002 03:38:42 -0700 From: Ben Jackson To: freebsd-net@freebsd.org Subject: kldload bridge insufficient: must use options BRIDGE Message-ID: <20020507103838.GA337@hubble.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 In brief, I think bridge(4) should be more explicit that `options BRIDGE' is required, even though `kldload bridge' seems to work. Alternatively, eliminate `#ifdef BRIDGE' in if_ether.c, so `kldload bridge' really does work. For the curious, and those searching the archives: I added a network card and bridged it to my (working) home lan interface. I was too lazy to build a new kernel, so I just used `kldload bridge', because it seemed to work. A client that worked on the home lan alllmost worked on the bridge side, but the server was unable to see its ARP replies. Using `arp -s' on the server got things going. I wondered if the ARP code was being overly paranoid about accepting replies on the "wrong" interface, and found the code in if_ether.c. Sure enough, in_arpinput it verifies that replies come in on the right interface, UNLESS we're bridging, but the code is only included if `options BRIDGE' is set. [sorry, I'm still not subscribed to this list, though I probably should, so pls cc me or mail directly if you have comments] -- 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 Wed May 8 19:42:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from jonkmans.com (dns01.jonkmans.com [64.239.6.30]) by hub.freebsd.org (Postfix) with ESMTP id F325A37B40A for ; Wed, 8 May 2002 19:42:10 -0700 (PDT) Received: from XP120634 (localhost.jonkmans.com [127.0.0.1]) by jonkmans.com (8.11.6/8.11.6) with SMTP id g492gEV86950 for ; Wed, 8 May 2002 21:42:14 -0500 (CDT) (envelope-from matt@jonkmans.com) Message-ID: <00dc01c1f703$1ddf71b0$2301070a@XP120634> From: "Matt Jonkman" To: Subject: MPD PPTP Routing problem Date: Wed, 8 May 2002 21:41:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm using mpd 3.2 on a freebsd 4.3 machine, ipfw with a pass any policy and a nat. The FreeBSD machine is a firewall with an internal network of 10.0.0.0/24, internal interface 10.0.0.65. I've got mpd configured to make the pptp connection, authentication and negotiation works beautifully. Client is an XP machine. I can send packets down the tunnel and can see them if I tcpdump the ng0 interface on the firewall, however I cannot get them any further than the ng0 interface it seems. A tcpdump of the internal interface shows absolutely no packets coming out, not even an arp request. The routing table on the client seems correct with a default route up the tunnel. I can ping the internal IP of the firewall, and the firewall can ping the tunnel ip of the client. What am I missing? This has got to be something simple. Can someone help me out? The relevant config snippets are below: mpd.conf: default: load pptp pptp: new -i ng0 pptp pptp set iface disable on-demand set iface enable proxy-arp set iface idle 1800 set iface route 10.0.0.0/24 set bundle disable multilink set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 10 60 set ipcp yes vjcomp set ipcp ranges 10.0.0.65/32 10.0.0.200/32 set ipcp dns 10.0.0.65 set ipcp nbns 10.0.0.3 # # The five lines below enable Microsoft Point-to-Point encryption # (MPPE) using the ng_mppc(8) netgraph node type. # set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless mpd.links: pptp: set link type pptp set pptp self set pptp enable incoming set pptp disable originate Any help is greatly appreciated. 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 9 0:19: 8 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 2072037B416 for ; Thu, 9 May 2002 00:19:05 -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 <20020508202950.LCQR22408.rwcrmhc53.attbi.com@blossom.cjclark.org>; Wed, 8 May 2002 20:29:50 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g48KTnN95156; Wed, 8 May 2002 13:29:49 -0700 (PDT) (envelope-from cjc) Date: Wed, 8 May 2002 13:29:49 -0700 From: "Crist J. Clark" To: Matthew Luckie Cc: freebsd-net@FreeBSD.ORG Subject: Re: log_arp_movements Message-ID: <20020508132949.A95125@blossom.cjclark.org> References: <3CD88C72.8030203@ihug.co.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CD88C72.8030203@ihug.co.nz>; from kluckie@ihug.co.nz on Wed, May 08, 2002 at 02:24:50PM +1200 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 Wed, May 08, 2002 at 02:24:50PM +1200, Matthew Luckie wrote: > Hi > > Any chance that the following patch could be MFC'd? > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/if_ether.c.diff?r1=1.80&r2=1.81 > > The format string passed to log has changed slightly in the previous 8 > months, but other than that it looks reasonably straight forward. *sigh* Rather than make a sysctl(8) for every single kernel message, I wish people would just use syslogd(8) features. -- 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 Thu May 9 2: 2:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from ccsun2.csie.nctu.edu.tw (ccsun2.csie.nctu.edu.tw [140.113.209.102]) by hub.freebsd.org (Postfix) with ESMTP id 2522437B416 for ; Thu, 9 May 2002 02:02:51 -0700 (PDT) Received: (from cfliu@localhost) by ccsun2.csie.nctu.edu.tw (8.9.3/8.9.0) id RAA09591 for freebsd-net@freebsd.org; Thu, 9 May 2002 17:06:54 +0800 (CST) From: "Vive l'amour" Message-Id: <200205090906.RAA09591@ccsun2.csie.nctu.edu.tw> Subject: Are there any documents for PCB hashing? To: freebsd-net@freebsd.org Date: Thu, 9 May 2002 17:06:53 +0800 (CST) X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I'd like to know if there are any tutorial or introduction documents that explains the PCB hashing in BSD kernel. Steven's TCPv2 didn't explain this becoz at the time he wrote the book, only one-behind cache was used. I'm confused at in_pcblookup_local() and in_pcblookup_hash(). In TCPv2, there is only a in_pcblookup and these hashing stuffs have confused me. What's the difference between the two calls?? Thank you very much David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 9 8:27:17 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 A29DF37B408 for ; Thu, 9 May 2002 08:27:11 -0700 (PDT) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g49FR8W89051; Thu, 9 May 2002 08:27:08 -0700 (PDT) (envelope-from rizzo) Date: Thu, 9 May 2002 08:27:08 -0700 From: Luigi Rizzo To: Archie Cobbs Cc: freebsd-net@FreeBSD.org Subject: Re: Transmitting packets when not IFF_UP Message-ID: <20020509082708.A87490@iguana.icir.org> References: <200205081902.g48J2aZ24545@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200205081902.g48J2aZ24545@arch20m.dellroad.org> 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 Wed, May 08, 2002 at 12:02:36PM -0700, Archie Cobbs wrote: > Several people using netgraph for bridging, PPPoE, or whatever > have encountered the problem where transmitting a packet out > an interface that is not marked IFF_UP causes a panic. This is sounds more or less ok, but then the same check should be added to bridge.c which possibly calls if_start. This said, do you have any reference or docs on the exact meaning of the various IFF_* flags, so we can give a sweep at the code and try to make things consistent and possibly centralised -- e.g. should we move the check for IFF_UP|IFF_RUNNING to IF_ENQUEUE (or whatever it is called in -current) so we do not need to bother in the drivers ? cheers luigi > because many drivers were written with the assumption that this > would never happen. > > To fix this once and for all I'd like to commit the patch below. > Comments and reviews warmly appreciated... > > Thanks, > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com > > Index: sys/net/if_ethersubr.c > =================================================================== > RCS file: /home/ncvs/src/sys/net/if_ethersubr.c,v > retrieving revision 1.110 > diff -u -U8 -r1.110 if_ethersubr.c > --- if_ethersubr.c 4 Apr 2002 05:42:09 -0000 1.110 > +++ if_ethersubr.c 8 May 2002 19:01:56 -0000 > @@ -372,16 +372,22 @@ > */ > int > ether_output_frame(ifp, m) > struct ifnet *ifp; > struct mbuf *m; > { > int error = 0; > > + /* Don't send packet if the interface is not up */ > + if ((ifp->if_flags & (IFF_UP|IFF_RUNNING)) != (IFF_UP|IFF_RUNNING)) { > + m_freem(m); > + return (ENETDOWN); > + } > + > if (BDG_ACTIVE(ifp) ) { > struct ether_header *eh; /* a ptr suffices */ > > m->m_pkthdr.rcvif = NULL; > eh = mtod(m, struct ether_header *); > m_adj(m, ETHER_HDR_LEN); > m = bdg_forward_ptr(m, eh, ifp); > if (m != NULL) > > 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 9 10: 0:51 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 679F537B417 for ; Thu, 9 May 2002 10:00:21 -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 JAA32451; Thu, 9 May 2002 09:52:56 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g49Gqs102639; Thu, 9 May 2002 09:52:55 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200205091652.g49Gqs102639@arch20m.dellroad.org> Subject: Re: Transmitting packets when not IFF_UP In-Reply-To: <20020509082708.A87490@iguana.icir.org> "from Luigi Rizzo at May 9, 2002 08:27:08 am" To: Luigi Rizzo Date: Thu, 9 May 2002 09:52:54 -0700 (PDT) Cc: freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Luigi Rizzo writes: > > Several people using netgraph for bridging, PPPoE, or whatever > > have encountered the problem where transmitting a packet out > > an interface that is not marked IFF_UP causes a panic. This is > > sounds more or less ok, but then the same check should be > added to bridge.c which possibly calls if_start. Probably so.. Also, I think a fix that is more consistent with the current code is to do this check within the ng_ether(4) node instead of in ether_output_frame(), because everybody else who calls ether_output_frame() already does this check (pointed out by Guido van Rooj). But longer term it may make sense to fold all of these checks into ether_output_frame(). Below is a replacement patch. > This said, do you have any reference or docs on the exact meaning > of the various IFF_* flags, so we can give a sweep at the code > and try to make things consistent and possibly centralised -- > e.g. should we move the check for IFF_UP|IFF_RUNNING to IF_ENQUEUE > (or whatever it is called in -current) so we do not need to bother > in the drivers ? No-- I've always wondered about that, e.g., the difference between IFF_UP and IFF_RUNNING... -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com Index: sys/netgraph/ng_ether.c =================================================================== RCS file: /home/ncvs/src/sys/netgraph/ng_ether.c,v retrieving revision 1.22 diff -u -r1.22 ng_ether.c --- ng_ether.c 5 Feb 2002 18:27:30 -0000 1.22 +++ ng_ether.c 9 May 2002 16:51:29 -0000 @@ -627,6 +627,14 @@ ng_ether_rcv_lower(node_p node, struct mbuf *m, meta_p meta) { const priv_p priv = NG_NODE_PRIVATE(node); + struct ifnet *const ifp = priv->ifp; + + /* Check whether interface is ready for packets */ + if ((ifp->if_flags & (IFF_UP|IFF_RUNNING)) != (IFF_UP|IFF_RUNNING)) { + NG_FREE_M(m); + NG_FREE_META(meta); + return (ENETDOWN); + } /* Make sure header is fully pulled up */ if (m->m_pkthdr.len < sizeof(struct ether_header)) { @@ -642,14 +650,14 @@ /* Drop in the MAC address if desired */ if (priv->autoSrcAddr) { - bcopy((IFP2AC(priv->ifp))->ac_enaddr, + bcopy((IFP2AC(ifp))->ac_enaddr, mtod(m, struct ether_header *)->ether_shost, ETHER_ADDR_LEN); } /* Send it on its way */ NG_FREE_META(meta); - return ether_output_frame(priv->ifp, m); + return ether_output_frame(ifp, m); } /* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 9 12:53:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by hub.freebsd.org (Postfix) with ESMTP id 4DD6837B409 for ; Thu, 9 May 2002 12:53:07 -0700 (PDT) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.1/8.12.1) with ESMTP id g49Jr44F099565 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 9 May 2002 12:53:05 -0700 (PDT)?g (envelope-from sam@errno.com)œ Message-ID: <09c401c1f793$22c6c670$52557f42@errno.com> From: "Sam Leffler" To: "Archie Cobbs" , "Luigi Rizzo" Cc: References: <200205091652.g49Gqs102639@arch20m.dellroad.org> Subject: Re: Transmitting packets when not IFF_UP Date: Thu, 9 May 2002 12:53:04 -0700 Organization: Errno Consulting 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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > This said, do you have any reference or docs on the exact meaning > > of the various IFF_* flags, so we can give a sweep at the code > > and try to make things consistent and possibly centralised -- > > e.g. should we move the check for IFF_UP|IFF_RUNNING to IF_ENQUEUE > > (or whatever it is called in -current) so we do not need to bother > > in the drivers ? > > No-- I've always wondered about that, e.g., the difference between > IFF_UP and IFF_RUNNING... Originally IFF_RUNNING meant the underlying hardware was setup and ready to go (probe+config had completed successfully). IFF_UP meant the network interface was fully configured and ready for packets. I don't recall if IFF_UP => IFF_RUNNING. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 9 12:55:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from spontoon.braithwaite.net (spontoon.braithwaite.net [207.135.122.130]) by hub.freebsd.org (Postfix) with ESMTP id 60F8437B40D; Thu, 9 May 2002 12:55:35 -0700 (PDT) Received: from dogberry.braithwaite.net (nat-236-141.cnet.com [64.124.236.141]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "dogberry.braithwaite.net", Issuer "Braithwaite's Certifying Authority" (verified OK)) by spontoon.braithwaite.net (Postfix) with ESMTP id 0096F7DF07; Thu, 9 May 2002 12:55:34 -0700 (PDT) Received: by dogberry.braithwaite.net (Postfix, from userid 1001) id 8B617924F; Thu, 9 May 2002 12:55:31 -0700 (PDT) From: Matthew Braithwaite To: Archie Cobbs Cc: David Gilbert , freebsd-stable@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: mpd-netgraph problem. References: <200202022113.g12LDs771403@arch20m.dellroad.org> Date: 09 May 2002 12:55:30 -0700 In-Reply-To: <200202022113.g12LDs771403@arch20m.dellroad.org> Message-ID: <86u1ph5c5p.fsf@limekiller.braithwaite.net> Lines: 82 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 2 Feb 2002 13:13:53 -0800 (PST), Archie Cobbs said: > > David Gilbert writes: > > > I'm using mpd-netgraph to attempt to connect an encrypted tunnel. > > It appears to connect (according to the messages), but the > > following is spit out for most packets I try to put down the > > tunnel: > > > > [vpn] LCP: rec'd Protocol Reject #1 link 0 (Opened) > > [vpn] LCP: protocol 0x0029 was rejected > > [vpn] LCP: rec'd Protocol Reject #2 link 0 (Opened) > > [vpn] LCP: protocol 0x00a1 was rejected > > This is usually because one side is sending encrypted traffic that > the other is thinking is not encrypted... i.e., it's a side-effect > of a negotiation problem. > > I've just heard from another person with this problem. Check your > logs for something like ``"enable chap" required for MPPE'' on one > side. > > As a workaround, if you are doing CHAP in both directions, try > turning it off in one direction. Archie, Can you explain a little more about this? I have just the same symptoms as this other guy, but I'm not having much luck with any of the fixes. Everything was working fine until recently, when the folks who run my Windows-based VPN server decided to require that everybody use 128-bit encryption. So I added the options: set ccp yes mppc set ccp yes mpp-e128 and although my connection comes up just fine, I'm now getting the same protocol rejects described above. I tried upgrading to mpd 3.8, as you suggested in another followup, but that didn't help. I do *not* get any message like ``"enable chap" required for MPPE''. The server authenticates me with CHAP, but I'm not authenticating the server -- which sounds like the workaround you suggest. Any thoughts? XXXvpn: new -i ng0 XXX vpn set log +pptp +pptp2 +pptp3 +lcp +auth set iface route default set iface disable on-demand set bundle authname XXX set bundle password "XXX" set ipcp ranges 0.0.0.0/0 0.0.0.0/0 set ipcp yes vjcomp set link disable chap pap set link accept chap pap set link yes acfcomp protocomp set iface route 10.0.0.0/8 set iface route 172.16.0.0/12 set iface route 192.168.0.0/16 set iface route XXX set iface route XXX set iface idle 0 set bundle disable multilink set link enable no-orig-auth set link keep-alive 10 75 set ipcp yes vjcomp set bundle enable compression set ccp yes mppc set ccp yes mpp-e128 open iface vpn: set link type pptp set pptp self 1.2.3.4 set pptp peer XXX set pptp enable originate outcall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 9 13:19:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from sabre.velocet.net (sabre.velocet.net [216.138.209.205]) by hub.freebsd.org (Postfix) with ESMTP id 9031F37B405; Thu, 9 May 2002 13:19:47 -0700 (PDT) Received: from trooper.velocet.ca (trooper.velocet.net [216.138.242.2]) by sabre.velocet.net (Postfix) with ESMTP id 9DF84137F4D; Thu, 9 May 2002 16:19:46 -0400 (EDT) Received: by trooper.velocet.ca (Postfix, from userid 101) id 69FCC2393; Thu, 9 May 2002 16:19:46 -0400 (EDT) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15578.55778.377759.555590@trooper.velocet.net> Date: Thu, 9 May 2002 16:19:46 -0400 To: Matthew Braithwaite Cc: Archie Cobbs , David Gilbert , freebsd-stable@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: mpd-netgraph problem. In-Reply-To: <86u1ph5c5p.fsf@limekiller.braithwaite.net> References: <200202022113.g12LDs771403@arch20m.dellroad.org> <86u1ph5c5p.fsf@limekiller.braithwaite.net> X-Mailer: VM 7.00 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid 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 never solved my problem. Since I control both ends, and there's no packet loss, I'm currently running ppp over ssh. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 9 13:30:19 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 B5AD937B41B; Thu, 9 May 2002 13:30: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 NAA33608; Thu, 9 May 2002 13:15:29 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g49KFRw03383; Thu, 9 May 2002 13:15:27 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200205092015.g49KFRw03383@arch20m.dellroad.org> Subject: Re: mpd-netgraph problem. In-Reply-To: <86u1ph5c5p.fsf@limekiller.braithwaite.net> "from Matthew Braithwaite at May 9, 2002 12:55:30 pm" To: Matthew Braithwaite Date: Thu, 9 May 2002 13:15:27 -0700 (PDT) Cc: Archie Cobbs , David Gilbert , freebsd-stable@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 Matthew Braithwaite writes: > > > [vpn] LCP: rec'd Protocol Reject #1 link 0 (Opened) > > > [vpn] LCP: protocol 0x0029 was rejected > > > [vpn] LCP: rec'd Protocol Reject #2 link 0 (Opened) > > > [vpn] LCP: protocol 0x00a1 was rejected > > > > This is usually because one side is sending encrypted traffic that > > the other is thinking is not encrypted... i.e., it's a side-effect > > of a negotiation problem. > > Everything was working fine until recently, when the folks who run my > Windows-based VPN server decided to require that everybody use 128-bit > encryption. So I added the options: > > set ccp yes mppc > set ccp yes mpp-e128 > > and although my connection comes up just fine, I'm now getting the > same protocol rejects described above. It may be that compression is actually not being negotiated properly, even though the link is staying up. Can you send me an mpd log trace? -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 9 13:39:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailout.informatik.tu-muenchen.de (mailout.informatik.tu-muenchen.de [131.159.0.5]) by hub.freebsd.org (Postfix) with ESMTP id 0E06B37B406 for ; Thu, 9 May 2002 13:39:32 -0700 (PDT) Received: from mailrelay1.informatik.tu-muenchen.de (mailrelay1.informatik.tu-muenchen.de [131.159.254.5]) by mailout.informatik.tu-muenchen.de (Postfix) with ESMTP id EAE5D6135 for ; Thu, 9 May 2002 22:39:30 +0200 (MEST) Received: from atrbg11.informatik.tu-muenchen.de (atrbg11.informatik.tu-muenchen.de [131.159.24.91]) by mailrelay1.informatik.tu-muenchen.de (Postfix) with ESMTP id BB1707942 for ; Thu, 9 May 2002 22:39:30 +0200 (MEST) Received: by atrbg11.informatik.tu-muenchen.de (Postfix, from userid 20455) id 7671D139C8; Thu, 9 May 2002 22:39:30 +0200 (CEST) Date: Thu, 9 May 2002 22:39:30 +0200 From: Daniel Lang To: freebsd-net@freebsd.org Subject: Multiple NICs on the same subnet Message-ID: <20020509203930.GA32900@atrbg11.informatik.tu-muenchen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i X-Geek: GCS/CC d-- s: a- C++$ UBS++++$ P+++$ L- E-(---) W+++(--) N++ o K w--- O? M? V? PS+(++) PE--(+) Y+ PGP+ t++ 5+++ X R+(-) tv+ b+ DI++ D++ G++ e+++ h---(-) r++>+++ y+ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I want to use multiple NICs on the same subnet. Thats my setup: FreeBSD 4.5-STABLE (updated 2-3 weeks ago, no 4.6-PRERELEASE yet), 3 NICs inside: 2 x 3com 905C-TX, 1 x D-Link DGE-500SX (Level 1 Gigabit). Now I want to assign a couple of IP addresses to those NICs. All IP addresses are on the same subnet, and they correspond to different kind of services available from this host, like FTP, CVSup, http, rsync, etc. Previously all services have been served by a single NIC, and I've used IP aliases to assign the service bound addresses to the NIC. Now I want to assign a certain set of services to different NICs (which all have separate uplinks at their switches and thus can achieve more bandwidth), like bind the FTP service to the lge interface, and maybe rsync and CVSup to one of the 3coms and the rest to the remaining 3com. This does not seem to be possible. If I want to assign an address to one of those NICs, I get an error from an ioctl like "file exists". Reading the archives, etc, it seems like I need to assign this address as an alias. This sort of worked. I could assign an address to one of the other NICs by choosing a netmask of /32 and stating alias on using ifconfig. But, our switch did not register any packets from one of the other NICs other than the default interface (one of the 3coms). It seems, like the address may be assigned to one of the NICs, but even if I use an application which explicitly binds to a certain source IP, the packet does not get sent by the interface, which has this IP address assigned, but by the default interface. This would not be that much of a problem so far. The problem really showed up, when it seemed like the Gigabit interface did not seem to work as expected. A couple of possible problems may be the cause, symptoms beeing "lge0: watchdog timeout" messages (which may be due to hardware/cabling problems), "sendto: no buffer space availble" messages (no idea where this comes from, any hints appreaciated, kern.ipc.nmbclusters and kern.maxusers etc, are bumped enough and did not max out (according to netstat -m)). So I thought, I run the production services on the reliable xl0 and xl1 interfaces and assign a test IP address to the lge0 interface, and if services from that interface run reliable, too, I switch the others over, benefitting from the increased bandwith. Well, thats how I would like it to work. But it doesn't. Is there any chance in FreeBSD to do it, and if, how? I've heard some rumours, it is not possible to use multiple NICs on the same subnet, since the IP stack would not know which interface to use to transmit packets, since it could not use its routing table (as the network is the same). But my argument would be, of course it should use the interface, which was configured with the address, the service bound its source port to. If any service did bind to IN_ADDR_ANY (0.0.0.0), the ip stack may choose the default interface or just any interface to transmit the packet from. I've also heard Bill Paul did some work on fat ethernet channels, which may be an implementation of Ciscos ethernet channel trunking/bundling, which also requires support from the switching counterpart. Although this is very interesting it does not help me at all, since I do not intend to bundle my NICs to a single fat channel, but to assign certain services to it, and to do some testing, but all on the same subnet. Any help greatly appreciated. Best regards, Daniel -- IRCnet: Mr-Spock - "I hear that, if you play the WindowsXP CD backwards, you get a Satanic message!" - "That's nothing. If you play it forward, it installs WindowsXP!" Daniel Lang * dl@leo.org * +49 89 289 25735 * http://www.leo.org/~dl/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 9 15:16:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from cody.jharris.com (cody.jharris.com [205.238.128.83]) by hub.freebsd.org (Postfix) with ESMTP id DF38537B407 for ; Thu, 9 May 2002 15:15:34 -0700 (PDT) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id g49MSDK24104; Thu, 9 May 2002 17:28:13 -0500 (CDT) (envelope-from nick@rogness.net) Date: Thu, 9 May 2002 17:28:13 -0500 (CDT) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Daniel Lang Cc: freebsd-net@FreeBSD.ORG Subject: Re: Multiple NICs on the same subnet In-Reply-To: <20020509203930.GA32900@atrbg11.informatik.tu-muenchen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 9 May 2002, Daniel Lang wrote: > Hi, > > I want to use multiple NICs on the same subnet. > Thats my setup: > > FreeBSD 4.5-STABLE (updated 2-3 weeks ago, no 4.6-PRERELEASE yet), > 3 NICs inside: 2 x 3com 905C-TX, 1 x D-Link DGE-500SX (Level 1 > Gigabit). > > Now I want to assign a couple of IP addresses to those NICs. All IP > addresses are on the same subnet, and they correspond to different > kind of services available from this host, like FTP, CVSup, http, > rsync, etc. > > Previously all services have been served by a single NIC, and I've > used IP aliases to assign the service bound addresses to the NIC. Now > I want to assign a certain set of services to different NICs (which > all have separate uplinks at their switches and thus can achieve more > bandwidth), like bind the FTP service to the lge interface, and maybe > rsync and CVSup to one of the 3coms and the rest to the remaining > 3com. > > This does not seem to be possible. If I want to assign an address to > one of those NICs, I get an error from an ioctl like "file exists". > Reading the archives, etc, it seems like I need to assign this address > as an alias. This sort of worked. I could assign an address to one of > the other NICs by choosing a netmask of /32 and stating alias on using > ifconfig. But, our switch did not register any packets from one of the > other NICs other than the default interface (one of the 3coms). It > seems, like the address may be assigned to one of the NICs, but even > if I use an application which explicitly binds to a certain source IP, > the packet does not get sent by the interface, which has this IP > address assigned, but by the default interface. The problem you are having is not an alias problem but a routing one. Packets come in to your alias on the proper interface but when the reply packet gets sent it uses the default route which goes out your default route. In other words, packets that arrive inbound on an interface will not necessarily leave that same interface on the outbound reply, if it doesn't have a route to that network via that interface. Instead, it leaves through the default gateway interface (because of the default route). The best way to handle this is with ipfw fwd. Basically you forward packets trying to leave the default gateway with the aliased address of a different interface out the right interface. For example: xl0 --> alias= 1.1.1.1/32 , (default gateway out this interface) xl1 --> alias= 1.1.1.2/32 lge0 --> alias= 1.1.1.3/32 ipfw ruleset: # FOrward packets properly ipfw fwd $IP_OF_NEXT_HOP_xl1 ip from 1.1.1.2/32 to any out via xl0 ipfw fwd $IP_OF_NEXT_HOP_lge0 ip from 1.1.1.3/32 to any out via xl0 . . . [rest of firewall] . . . You will need your kernel build with 'options IPFIREWALL_FORWARD'. > > This would not be that much of a problem so far. The problem really > showed up, when it seemed like the Gigabit interface did not seem to > work as expected. A couple of possible problems may be the cause, > symptoms beeing "lge0: watchdog timeout" messages (which may be due to > hardware/cabling problems), "sendto: no buffer space availble" > messages (no idea where this comes from, any hints appreaciated, > kern.ipc.nmbclusters and kern.maxusers etc, are bumped enough and did > not max out (according to netstat -m)). This is another problem altogether. > So I thought, I run the production services on the reliable xl0 and > xl1 interfaces and assign a test IP address to the lge0 interface, and > if services from that interface run reliable, too, I switch the others > over, benefitting from the increased bandwith. > > Well, thats how I would like it to work. But it doesn't. Is there any > chance in FreeBSD to do it, and if, how? > > I've heard some rumours, it is not possible to use multiple NICs on > the same subnet, since the IP stack would not know which interface to > use to transmit packets, since it could not use its routing table (as > the network is the same). But my argument would be, of course it > should use the interface, which was configured with the address, the > service bound its source port to. If any service did bind to > IN_ADDR_ANY (0.0.0.0), the ip stack may choose the default interface > or just any interface to transmit the packet from. Nick Rogness - Don't mind me...I'm just sniffing your packets To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 9 15:28:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from spontoon.braithwaite.net (spontoon.braithwaite.net [207.135.122.130]) by hub.freebsd.org (Postfix) with ESMTP id 2883237B40D; Thu, 9 May 2002 15:27:57 -0700 (PDT) Received: from dogberry.braithwaite.net (nat-236-141.cnet.com [64.124.236.141]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "dogberry.braithwaite.net", Issuer "Braithwaite's Certifying Authority" (verified OK)) by spontoon.braithwaite.net (Postfix) with ESMTP id AC4B37DF01; Thu, 9 May 2002 15:27:55 -0700 (PDT) Received: by dogberry.braithwaite.net (Postfix, from userid 1001) id 25F82924F; Thu, 9 May 2002 15:27:53 -0700 (PDT) From: Matthew Braithwaite To: Archie Cobbs Cc: Matthew Braithwaite , David Gilbert , freebsd-stable@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: mpd-netgraph problem. References: <200205092015.g49KFRw03383@arch20m.dellroad.org> Date: 09 May 2002 15:27:53 -0700 In-Reply-To: <200205092015.g49KFRw03383@arch20m.dellroad.org> Message-ID: <86k7qd553q.fsf@limekiller.braithwaite.net> Lines: 201 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 9 May 2002 13:15:27 -0700 (PDT), Archie Cobbs said: > > It may be that compression is actually not being negotiated > properly, even though the link is staying up. Can you send me an mpd > log trace? Do you need more debugging turned on than this? Note: right now I'm actually inside the network I'm VPN-ing to. This doesn't seem to cause any problems setting up the connection, but I thought I had better mention it. :-) Multi-link PPP for FreeBSD, by Archie L. Cobbs. Based on iij-ppp, by Toshiharu OHNO. mpd: pid 30437, version 3.8 (root@dogberry.braithwaite.net 08:31 9-May-2002) [XXX] ppp node is "mpd30437-XXX" [XXX] using interface ng0 Usage: set login [authname] [XXX] IPCP: peer address cannot be zero [XXX] IFACE: Open event [XXX] IPCP: Open event [XXX] IPCP: state change Initial --> Starting [XXX] IPCP: LayerStart [XXX:vpn] [XXX] bundle: OPEN event in state CLOSED [XXX] opening link "vpn"... [vpn] link: OPEN event [vpn] LCP: Open event [vpn] LCP: state change Initial --> Starting [vpn] LCP: LayerStart [vpn] device: OPEN event in state DOWN pptp0: connecting to XXX:1723 [vpn] device is now in state OPENING pptp0: connected to XXX:1723 pptp0: attached to connection with XXX:1723 pptp0-0: outgoing call connected at 64000 bps [vpn] PPTP call successful [vpn] device: UP event in state OPENING [vpn] device is now in state UP [vpn] link: UP event [vpn] link: origination is local [vpn] LCP: Up event [vpn] LCP: state change Starting --> Req-Sent [vpn] LCP: phase shift DEAD --> ESTABLISH [vpn] LCP: SendConfigReq #1 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM bc0c9f45 [vpn] LCP: SendConfigReq #2 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM bc0c9f45 [vpn] LCP: rec'd Configure Ack #2 link 0 (Req-Sent) ACFCOMP PROTOCOMP MRU 1500 MAGICNUM bc0c9f45 [vpn] LCP: state change Req-Sent --> Ack-Rcvd [vpn] LCP: rec'd Configure Request #250 link 0 (Ack-Rcvd) MRU 1500 ACCMAP 0x000a0000 AUTHPROTO CHAP MSOFTv2 MAGICNUM 43a911e1 PROTOCOMP ACFCOMP [vpn] LCP: SendConfigAck #250 MRU 1500 ACCMAP 0x000a0000 AUTHPROTO CHAP MSOFTv2 MAGICNUM 43a911e1 PROTOCOMP ACFCOMP [vpn] LCP: state change Ack-Rcvd --> Opened [vpn] LCP: phase shift ESTABLISH --> AUTHENTICATE [vpn] LCP: auth: peer wants CHAP, I want nothing [vpn] LCP: LayerUp [vpn] CHAP: rec'd CHALLENGE #173 Name: "10.16.97.5" Using authname "XXX" [vpn] CHAP: sending RESPONSE [vpn] LCP: rec'd Configure Request #172 link 0 (Opened) MRU 1500 ACCMAP 0x000a0000 AUTHPROTO CHAP MSOFT MAGICNUM 3ce7fe6d PROTOCOMP ACFCOMP [vpn] LCP: LayerDown [vpn] LCP: SendConfigReq #3 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM bc0c9f45 [vpn] LCP: SendConfigAck #172 MRU 1500 ACCMAP 0x000a0000 AUTHPROTO CHAP MSOFT MAGICNUM 3ce7fe6d PROTOCOMP ACFCOMP [vpn] LCP: state change Opened --> Ack-Sent [vpn] LCP: phase shift AUTHENTICATE --> ESTABLISH [vpn] LCP: rec'd Configure Ack #3 link 0 (Ack-Sent) ACFCOMP PROTOCOMP MRU 1500 MAGICNUM bc0c9f45 [vpn] LCP: state change Ack-Sent --> Opened [vpn] LCP: phase shift ESTABLISH --> AUTHENTICATE [vpn] LCP: auth: peer wants CHAP, I want nothing [vpn] LCP: LayerUp [vpn] CHAP: rec'd CHALLENGE #173 Name: "10.16.97.5" Using authname "XXX" [vpn] CHAP: sending RESPONSE [vpn] CHAP: rec'd SUCCESS #173 MESG: CHAP authentication success, unit 116043796 [vpn] LCP: authorization successful [vpn] LCP: phase shift AUTHENTICATE --> NETWORK [XXX] up: 1 link, total bandwidth 64000 bps [XXX] IPCP: Up event [XXX] IPCP: state change Starting --> Req-Sent [XXX] IPCP: SendConfigReq #1 IPADDR 0.0.0.0 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [XXX] CCP: Open event [XXX] CCP: state change Initial --> Starting [XXX] CCP: LayerStart [XXX] CCP: Up event [XXX] CCP: state change Starting --> Req-Sent [XXX] CCP: SendConfigReq #1 MPPC 0x00000040: MPPE, 128 bit [XXX] IPCP: rec'd Configure Request #141 link 0 (Req-Sent) IPADDR 10.16.97.5 10.16.97.5 is OK COMPPROTO VJCOMP, 8 comp. channels, no comp-cid [XXX] IPCP: SendConfigAck #141 IPADDR 10.16.97.5 COMPPROTO VJCOMP, 8 comp. channels, no comp-cid [XXX] IPCP: state change Req-Sent --> Ack-Sent [XXX] IPCP: rec'd Configure Nak #1 link 0 (Ack-Sent) IPADDR 10.16.97.42 10.16.97.42 is OK COMPPROTO VJCOMP, 8 comp. channels, no comp-cid Adjusting # compression channels [XXX] IPCP: SendConfigReq #2 IPADDR 10.16.97.42 COMPPROTO VJCOMP, 8 comp. channels, no comp-cid [XXX] CCP: rec'd Configure Request #21 link 0 (Req-Sent) MPPC 0x00000040: MPPE, 128 bit [XXX] CCP: SendConfigAck #21 MPPC 0x00000040: MPPE, 128 bit [XXX] CCP: state change Req-Sent --> Ack-Sent [XXX] CCP: rec'd Configure Ack #1 link 0 (Ack-Sent) MPPC 0x00000040: MPPE, 128 bit [XXX] CCP: state change Ack-Sent --> Opened [XXX] CCP: LayerUp Compress using: MPPE, 128 bit Decompress using: MPPE, 128 bit [XXX] IPCP: rec'd Configure Ack #2 link 0 (Ack-Sent) IPADDR 10.16.97.42 COMPPROTO VJCOMP, 8 comp. channels, no comp-cid [XXX] IPCP: state change Ack-Sent --> Opened [XXX] IPCP: LayerUp 10.16.97.42 -> 10.16.97.5 [XXX] IFACE: Up event [XXX] exec: /sbin/ifconfig ng0 10.16.97.42 10.16.97.5 netmask 0xffffffff -link0 [XXX] exec: /sbin/route add 0.0.0.0 10.16.97.5 [XXX] exec: command returned 256 [XXX] exec: /sbin/route add 10.0.0.0 10.16.97.5 -netmask 0xff000000 [XXX] exec: /sbin/route add 172.16.0.0 10.16.97.5 -netmask 0xfff00000 [XXX] exec: /sbin/route add 192.168.0.0 10.16.97.5 -netmask 0xffff0000 [XXX] exec: /sbin/route add XXX 10.16.97.5 -netmask 0xfffffe00 [XXX] exec: /sbin/route add XXX 10.16.97.5 -netmask 0xffffff00 [XXX] IFACE: Up event [vpn] LCP: rec'd Protocol Reject #173 link 0 (Opened) [vpn] LCP: protocol 0x5b49 was rejected [vpn] LCP: rec'd Protocol Reject #174 link 0 (Opened) [vpn] LCP: protocol 0xd951 was rejected ^Cmpd: caught fatal signal int mpd: fatal error, exiting [XXX] IPCP: Down event [XXX] IPCP: state change Opened --> Starting [XXX] IPCP: LayerDown [XXX] IFACE: Down event [XXX] exec: /sbin/route delete 10.0.0.0 10.16.97.5 -netmask 0xff000000 [XXX] exec: /sbin/route delete 172.16.0.0 10.16.97.5 -netmask 0xfff00000 [XXX] exec: /sbin/route delete 192.168.0.0 10.16.97.5 -netmask 0xffff0000 [XXX] exec: /sbin/route delete XXX 10.16.97.5 -netmask 0xfffffe00 [XXX] exec: /sbin/route delete XXX 10.16.97.5 -netmask 0xffffff00 [XXX] exec: /sbin/ifconfig ng0 down delete -link0 [XXX] IFACE: Close event [XXX] IPCP: Close event [XXX] IPCP: state change Starting --> Initial [XXX] IPCP: LayerFinish mpd: process 30437 terminated To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 9 16: 0:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id AB81C37B40F; Thu, 9 May 2002 16:00:42 -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 PAA34574; Thu, 9 May 2002 15:51:11 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g49Mp9C04122; Thu, 9 May 2002 15:51:09 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200205092251.g49Mp9C04122@arch20m.dellroad.org> Subject: Re: mpd-netgraph problem. In-Reply-To: <86k7qd553q.fsf@limekiller.braithwaite.net> "from Matthew Braithwaite at May 9, 2002 03:27:53 pm" To: Matthew Braithwaite Date: Thu, 9 May 2002 15:51:09 -0700 (PDT) Cc: dgilbert@velocet.ca, 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 [ note: removing -stable from the CC: list ] Matthew Braithwaite writes: > [vpn] LCP: rec'd Configure Request #250 link 0 (Ack-Rcvd) > MRU 1500 > ACCMAP 0x000a0000 > AUTHPROTO CHAP MSOFTv2 > MAGICNUM 43a911e1 > PROTOCOMP > ACFCOMP > [vpn] LCP: SendConfigAck #250 > MRU 1500 > ACCMAP 0x000a0000 > AUTHPROTO CHAP MSOFTv2 > MAGICNUM 43a911e1 > PROTOCOMP > ACFCOMP > [vpn] LCP: state change Ack-Rcvd --> Opened > [vpn] LCP: phase shift ESTABLISH --> AUTHENTICATE > [vpn] LCP: auth: peer wants CHAP, I want nothing > [vpn] LCP: LayerUp > [vpn] CHAP: rec'd CHALLENGE #173 > Name: "10.16.97.5" > Using authname "XXX" > [vpn] CHAP: sending RESPONSE > [vpn] LCP: rec'd Configure Request #172 link 0 (Opened) > MRU 1500 > ACCMAP 0x000a0000 > AUTHPROTO CHAP MSOFT > MAGICNUM 3ce7fe6d > PROTOCOMP > ACFCOMP > [vpn] LCP: LayerDown There is the problem... the machine you are talking to first asks you to authenticate via CHAP MSOFTv2, and then immediately after that asks you to authenticate via CHAP MSOFTv1. You don't even get a yes/no from the first authentication response. So that's screwey if you're doing MPPE encryption because which authentication do you use to generate the MPPE keys?? Apparently we are using the wrong one. In any case, we can't use the first one because we'd need the yes/no response to generate MPPE keys from CHAP MSOFTv2 authentication. And why is it authenticating you twice in the first place? -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 9 16:46: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from spontoon.braithwaite.net (spontoon.braithwaite.net [207.135.122.130]) by hub.freebsd.org (Postfix) with ESMTP id A448037B401 for ; Thu, 9 May 2002 16:46:05 -0700 (PDT) Received: from dogberry.braithwaite.net (nat-236-141.cnet.com [64.124.236.141]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "dogberry.braithwaite.net", Issuer "Braithwaite's Certifying Authority" (verified OK)) by spontoon.braithwaite.net (Postfix) with ESMTP id 5BC587DF05; Thu, 9 May 2002 16:45:59 -0700 (PDT) Received: by dogberry.braithwaite.net (Postfix, from userid 1001) id 68C99924F; Thu, 9 May 2002 16:45:57 -0700 (PDT) Date: Thu, 9 May 2002 16:45:57 -0700 From: Matthew Braithwaite To: Archie Cobbs Cc: Matthew Braithwaite , dgilbert@velocet.ca, freebsd-net@FreeBSD.ORG Subject: Re: mpd-netgraph problem. Message-ID: <20020509164557.A28528@dogberry.braithwaite.net> References: <86k7qd553q.fsf@limekiller.braithwaite.net> <200205092251.g49Mp9C04122@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200205092251.g49Mp9C04122@arch20m.dellroad.org>; from archie@dellroad.org on Thu, May 09, 2002 at 03:51:09PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, May 09, 2002 at 03:51:09PM -0700, Archie Cobbs wrote: > > So that's screwey if you're doing MPPE encryption because which > authentication do you use to generate the MPPE keys?? Apparently > we are using the wrong one. In any case, we can't use the first > one because we'd need the yes/no response to generate MPPE keys > from CHAP MSOFTv2 authentication. Let me see if I understand: a key used in CHAP authentication is also used for MPPE. However, I authenticate twice, once using CHAP MSOFTv2 and once using CHAP MSOFTv2 -- and you think mpd is choosing the MPPE key from the wrong one of these two authentications? Is there a way to fix this in mpd? According to the manual you *have* to use CHAP MSOFTv2 to use MPPE, so I'd think it'd be okay to categorically ignore -- for MPPE purposes -- any key obtained through a CHAP MSOFTv1 authentication. Can I force mpd to speak *only* CHAP MSOFTv2? I don't find any such option in the manual, unfortunately. > And why is it authenticating you twice in the first place? I don't know. Any suggestions on how I can perturb this behavior? I couldn't find any likely candidates in the manual. I could also go ask the guys who run the VPN server, but I'm unlikely to get a useful response, since It Works With Windows. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 9 17:15: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 8CFA437B417 for ; Thu, 9 May 2002 17: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 QAA34922; Thu, 9 May 2002 16:57:39 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g49Nvb204332; Thu, 9 May 2002 16:57:37 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200205092357.g49Nvb204332@arch20m.dellroad.org> Subject: Re: mpd-netgraph problem. In-Reply-To: <20020509164557.A28528@dogberry.braithwaite.net> "from Matthew Braithwaite at May 9, 2002 04:45:57 pm" To: Matthew Braithwaite Date: Thu, 9 May 2002 16:57:37 -0700 (PDT) Cc: Archie Cobbs , dgilbert@velocet.ca, 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 Matthew Braithwaite writes: > > So that's screwey if you're doing MPPE encryption because which > > authentication do you use to generate the MPPE keys?? Apparently > > we are using the wrong one. In any case, we can't use the first > > one because we'd need the yes/no response to generate MPPE keys > > from CHAP MSOFTv2 authentication. > > Let me see if I understand: a key used in CHAP authentication is also > used for MPPE. However, I authenticate twice, once using CHAP MSOFTv2 > and once using CHAP MSOFTv2 -- and you think mpd is choosing the MPPE > key from the wrong one of these two authentications? Once using MSOFTv2 and then a second time using MSOFTv1. According to RFC 3079, you should generate the keys from the first authentication. However, this is impossible because your server is never completing that authentication. > Is there a way to fix this in mpd? According to the manual you *have* > to use CHAP MSOFTv2 to use MPPE, so I'd think it'd be okay to > categorically ignore -- for MPPE purposes -- any key obtained through > a CHAP MSOFTv1 authentication. The manual is wrong; you can generate keys from MSOFTv1 or MSOFTv2. See RFC 3079. > Can I force mpd to speak *only* CHAP MSOFTv2? I don't find any such > option in the manual, unfortunately. No, that needs to be added... -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 9 20:17:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from spontoon.braithwaite.net (spontoon.braithwaite.net [207.135.122.130]) by hub.freebsd.org (Postfix) with ESMTP id 3F23837B404 for ; Thu, 9 May 2002 20:17:44 -0700 (PDT) Received: from dogberry.braithwaite.net (nat-236-141.cnet.com [64.124.236.141]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "dogberry.braithwaite.net", Issuer "Braithwaite's Certifying Authority" (verified OK)) by spontoon.braithwaite.net (Postfix) with ESMTP id D249F7DF03; Thu, 9 May 2002 20:17:42 -0700 (PDT) Received: by dogberry.braithwaite.net (Postfix, from userid 1001) id 7D6F0924F; Thu, 9 May 2002 20:17:41 -0700 (PDT) From: Matthew Braithwaite To: Archie Cobbs Cc: Matthew Braithwaite , dgilbert@velocet.ca, freebsd-net@FreeBSD.ORG Subject: Re: mpd-netgraph problem. References: <200205092357.g49Nvb204332@arch20m.dellroad.org> Date: 09 May 2002 20:17:41 -0700 In-Reply-To: <200205092357.g49Nvb204332@arch20m.dellroad.org> Message-ID: <86bsbo6696.fsf@limekiller.braithwaite.net> Lines: 48 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 9 May 2002 16:57:37 -0700 (PDT), Archie Cobbs said: > >> Let me see if I understand: a key used in CHAP authentication is >> also used for MPPE. However, I authenticate twice, once using CHAP >> MSOFTv2 and once using CHAP MSOFTv2 -- and you think mpd is >> choosing the MPPE key from the wrong one of these two >> authentications? > > Once using MSOFTv2 and then a second time using MSOFTv1. > According to RFC 3079, you should generate the keys from > the first authentication. However, this is impossible because > your server is never completing that authentication. So I assume that a completed authentication looks like this: [vpn] CHAP: rec'd CHALLENGE #173 Name: "10.16.97.5" Using authname "XXX" [vpn] CHAP: sending RESPONSE [vpn] CHAP: rec'd SUCCESS #173 i.e. the `received SUCCESS' is the important bit. You say that it's impossible to use the keys from the first authentication because the server doesn't complete it. So that means that after I send my response to the server's challenge, the server sends back some string of bits I need for encryption ... is that what this bit of code does? /* Need to remember MS-CHAP stuff for use with MPPE encryption */ if (chap->recv_alg == CHAP_ALG_MSOFTv2) { if (!memcmp(bund->peer_ntResp, gMsoftZeros, CHAP_MSOFTv2_RESP_LEN)) { memcpy(bund->peer_ntResp, chap_value + offsetof(struct mschapv2value, ntHash), CHAP_MSOFTv2_RESP_LEN); } } If the response I to my first authentication is what I need to encrypt my traffic, it seems unreasonable of the server not to send it. (One things that's odd about my authentication -- this was pointed out to me by the Windows boys, whom I'm sorry I dissed -- is that all the Windows users seem to authenticate as ``domain\\user'' whereas I authenticate as just ``user''. Who knows what that difference might tickle.) Do you have any suggestions for stuff I can try? I've been hacking at the mpd code a little bit, but I'm pretty ignorant, so it's slow going. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 9 20:32:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from spontoon.braithwaite.net (spontoon.braithwaite.net [207.135.122.130]) by hub.freebsd.org (Postfix) with ESMTP id CCB7E37B401 for ; Thu, 9 May 2002 20:32:23 -0700 (PDT) Received: from dogberry.braithwaite.net (nat-236-141.cnet.com [64.124.236.141]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "dogberry.braithwaite.net", Issuer "Braithwaite's Certifying Authority" (verified OK)) by spontoon.braithwaite.net (Postfix) with ESMTP id 263B57DF03; Thu, 9 May 2002 20:32:23 -0700 (PDT) Received: by dogberry.braithwaite.net (Postfix, from userid 1001) id 1FCA4924F; Thu, 9 May 2002 20:32:22 -0700 (PDT) Date: Thu, 9 May 2002 20:32:22 -0700 From: Matthew Braithwaite To: Matthew Braithwaite Cc: Archie Cobbs , dgilbert@velocet.ca, freebsd-net@FreeBSD.ORG Subject: Re: mpd-netgraph problem. Message-ID: <20020509203222.B28528@dogberry.braithwaite.net> References: <200205092357.g49Nvb204332@arch20m.dellroad.org> <86bsbo6696.fsf@limekiller.braithwaite.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <86bsbo6696.fsf@limekiller.braithwaite.net>; from matt@braithwaite.net on Thu, May 09, 2002 at 08:17:41PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, May 09, 2002 at 08:17:41PM -0700, Matthew Braithwaite wrote: > > (One things that's odd about my authentication -- this was pointed out > to me by the Windows boys, whom I'm sorry I dissed -- is that all the > Windows users seem to authenticate as ``domain\\user'' whereas I > authenticate as just ``user''. Who knows what that difference might > tickle.) One other datum: I was just able to snoop a Windows 98 user connecting to the same VPN server, and he also gets the double-authentication. The sequence is: LCP-configure-request MS-CHAPv2 LCP-configure-ack MS-CHAPv2 CHAP Challenge CHAP Response LCP-configure-request MS-CHAP LCP-configure-request compression LCP-configure-ack compression LCP-configure-ack MS-CHAP CHAP Challenge CHAP Response CHAP Success Note: no response to the first CHAP response. So whatever else may be true, the lack of that response doesn't prevent clients from speaking with this VPN server. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 10 1:31:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailout.informatik.tu-muenchen.de (mailout.informatik.tu-muenchen.de [131.159.0.5]) by hub.freebsd.org (Postfix) with ESMTP id B769137B404 for ; Fri, 10 May 2002 01:31:35 -0700 (PDT) Received: from mailrelay2.informatik.tu-muenchen.de (mailrelay.informatik.tu-muenchen.de [131.159.2.33]) by mailout.informatik.tu-muenchen.de (Postfix) with ESMTP id 8DB4E6248; Fri, 10 May 2002 10:31:34 +0200 (MEST) Received: from atrbg11.informatik.tu-muenchen.de (atrbg11.informatik.tu-muenchen.de [131.159.24.91]) by mailrelay2.informatik.tu-muenchen.de (Postfix) with ESMTP id 76A0147384; Fri, 10 May 2002 10:31:34 +0200 (MEST) Received: by atrbg11.informatik.tu-muenchen.de (Postfix, from userid 20455) id 15B08139C8; Fri, 10 May 2002 10:31:34 +0200 (CEST) Date: Fri, 10 May 2002 10:31:34 +0200 From: Daniel Lang To: Scott Ullrich Cc: freebsd-net@freebsd.org Subject: Re: Multiple NICs on the same subnet Message-ID: <20020510083134.GD33751@atrbg11.informatik.tu-muenchen.de> References: <2F6DCE1EFAB3BC418B5C324F13934C96016C9A58@exchange.corp.cre8.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2F6DCE1EFAB3BC418B5C324F13934C96016C9A58@exchange.corp.cre8.com> User-Agent: Mutt/1.3.27i X-Geek: GCS/CC d-- s: a- C++$ UBS++++$ P+++$ L- E-(---) W+++(--) N++ o K w--- O? M? V? PS+(++) PE--(+) Y+ PGP+ t++ 5+++ X R+(-) tv+ b+ DI++ D++ G++ e+++ h---(-) r++>+++ y+ 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 Scott, Scott Ullrich wrote on Thu, May 09, 2002 at 05:41:24PM -0400: > Are you using a fairly recent version of 4.5? I have mad much better luck > with maxusers 0? It's recent enough to allow to set it to 0, but I did not try it. I've talked to Mike Silbersack about this a while ago, and the 'autosizing' just picks a reasonable value, according to your RAM. I've even bumped maxusers to 768 which should be the same value as chosen by the autosizing. I don't run into any problems now, but I don't use the Gigabit link at the moment. I first need to find a way to test it reliably, before I put all services on that one. > I'm sure you've covered all the tracks... Just thinking out loud. ;) > > > -----Original Message----- > > From: Daniel Lang [mailto:dl@leo.org] > > Sent: Thursday, May 09, 2002 5:39 PM > > To: Scott Ullrich > > Subject: Re: Multiple NICs on the same subnet > > > > > > Dear Scott, > > > > Scott Ullrich wrote on Thu, May 09, 2002 at 04:41:42PM -0400: > > > Hey, can you post your kernel config file? It sounds like > > your running out > > > of resources. > > [..] > > > > I want to use multiple NICs on the same subnet. > > > > Thats my setup: > > > > Well, depends on what you are referring to. The problems with > > the lge0 gigabit NIC may be due to lack of ressources. I can > > post my kernel config, but I would not like to SPAM a whole > > lot of people with lots of useless information. So > > if you have some specific parameter in mind, I would prefer > > to tell you those, instead of a whole lot of drivers and > > stuff which is not so interesting. > > > > FYI: > > maxusers is set to 512, nmbclusters is set to 32768. > > the box has 1.5GB RAM. > > > > Thanks already. > > > > Best regards, > > Daniel > > -- > > IRCnet: Mr-Spock - Agartim billiard bumba m'abdul in > > papejim twista > > - rumba rock n rolla. Leik'ab mai. Spirzon Heroin se'osit > > gaula. - > > - Marijuana esit gaula. Haschisch. Opis. - > > *Daniel Lang * dl@leo.org * +49 89 289 25735 * > > http://www.leo.org/~dl/* > > -- IRCnet: Mr-Spock - All your .sigs are belong to us - Daniel Lang * dl@leo.org * +49 89 289 25735 * http://www.leo.org/~dl/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 10 1:44:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailout.informatik.tu-muenchen.de (mailout.informatik.tu-muenchen.de [131.159.0.5]) by hub.freebsd.org (Postfix) with ESMTP id 8E26737B40B for ; Fri, 10 May 2002 01:44:20 -0700 (PDT) Received: from mailrelay1.informatik.tu-muenchen.de (mailrelay1.informatik.tu-muenchen.de [131.159.254.5]) by mailout.informatik.tu-muenchen.de (Postfix) with ESMTP id E39DC6247; Fri, 10 May 2002 10:44:19 +0200 (MEST) Received: from atrbg11.informatik.tu-muenchen.de (atrbg11.informatik.tu-muenchen.de [131.159.24.91]) by mailrelay1.informatik.tu-muenchen.de (Postfix) with ESMTP id D09857942; Fri, 10 May 2002 10:44:19 +0200 (MEST) Received: by atrbg11.informatik.tu-muenchen.de (Postfix, from userid 20455) id 580F2139C8; Fri, 10 May 2002 10:44:19 +0200 (CEST) Date: Fri, 10 May 2002 10:44:19 +0200 From: Daniel Lang To: Nick Rogness Cc: freebsd-net@FreeBSD.ORG Subject: Re: Multiple NICs on the same subnet Message-ID: <20020510084419.GE33751@atrbg11.informatik.tu-muenchen.de> References: <20020509203930.GA32900@atrbg11.informatik.tu-muenchen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-Geek: GCS/CC d-- s: a- C++$ UBS++++$ P+++$ L- E-(---) W+++(--) N++ o K w--- O? M? V? PS+(++) PE--(+) Y+ PGP+ t++ 5+++ X R+(-) tv+ b+ DI++ D++ G++ e+++ h---(-) r++>+++ y+ 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 Nick, Nick Rogness wrote on Thu, May 09, 2002 at 05:28:13PM -0500: [..] > The problem you are having is not an alias problem but a routing > one. Packets come in to your alias on the proper interface but > when the reply packet gets sent it uses the default route which > goes out your default route. ^^^^^ interface I assume. Yes, true, that is probably the case. Looking at my routing tables, this makes sense. > In other words, packets that arrive inbound on an interface will > not necessarily leave that same interface on the outbound reply, > if it doesn't have a route to that network via that > interface. Instead, it leaves through the default gateway > interface (because of the default route). I see. > The best way to handle this is with ipfw fwd. Basically you > forward packets trying to leave the default gateway with the > aliased address of a different interface out the right interface. > > For example: > > xl0 --> alias= 1.1.1.1/32 , (default gateway out this interface) > xl1 --> alias= 1.1.1.2/32 > lge0 --> alias= 1.1.1.3/32 > > ipfw ruleset: > > # FOrward packets properly > ipfw fwd $IP_OF_NEXT_HOP_xl1 ip from 1.1.1.2/32 to any out via xl0 > ipfw fwd $IP_OF_NEXT_HOP_lge0 ip from 1.1.1.3/32 to any out via xl0 > . . . [rest of firewall] . . . Hmmm hm hm hm :-) May work. I can try it... I hope the additional forwarding code does not slow things down too much, but I guess not. > You will need your kernel build with 'options IPFIREWALL_FORWARD'. Ok thanks. Is that option set on building the ipfw.ko ? Anyway I try it. Maybe ipfilter works alike. > > This would not be that much of a problem so far. The problem really > > showed up, when it seemed like the Gigabit interface did not seem to > > work as expected. A couple of possible problems may be the cause, > > symptoms beeing "lge0: watchdog timeout" messages (which may be due to > > hardware/cabling problems), "sendto: no buffer space availble" > > messages (no idea where this comes from, any hints appreaciated, > > kern.ipc.nmbclusters and kern.maxusers etc, are bumped enough and did > > not max out (according to netstat -m)). > > This is another problem altogether. Yes. Any hints or suggestsion? I've got kern.maxuser=768 and kern.ipc.nmbcluster=32768 now. Maybe that solves it... [..] Thanks a lot for your help. Best regards, Daniel -- IRCnet: Mr-Spock - signs of absurd developments in the net community: #42: - "Wurstbrot gehoert m.E. zum Fruehstuecks-botnet von Cartoon" - *Daniel Lang * dl@leo.org * +49 89 289 25735 * http://www.leo.org/~dl/* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 10 3:15:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from sophia.inria.fr (sophia.inria.fr [138.96.64.20]) by hub.freebsd.org (Postfix) with ESMTP id 373CC37B403; Fri, 10 May 2002 03:15:37 -0700 (PDT) Received: from localhost (odie.inria.fr [138.96.88.52]) by sophia.inria.fr (8.11.6/8.11.6) with ESMTP id g4AAFSa22699; Fri, 10 May 2002 12:15:29 +0200 X-Authentication-Warning: sophia.inria.fr: Host odie.inria.fr [138.96.88.52] claimed to be localhost Date: Fri, 10 May 2002 12:15:27 +0200 (MEST) Message-Id: <20020510.121527.14198322.Hitoshi.Asaeda@sophia.inria.fr> To: brunner@nic-naa.net Cc: c.prevotaux@hexanet.fr, freebsd-net@FreeBSD.ORG, freebsd-hardware@FreeBSD.ORG Subject: Re: UDLR From: Hitoshi Asaeda In-Reply-To: <200205081823.g48IN4kx068826@nic-naa.net> References: <20020508151015.1a1c392f.c.prevotaux@hexanet.fr> <200205081823.g48IN4kx068826@nic-naa.net> X-Mailer: Mew version 2.2rc1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Emmanuel Duros already left INRIA. (So, there may be some old links from our pages, sorry.) Now, he is working at UDcast. Namely, this company is selling/providing UDLR functions. If you are interested in their services, you may want to mail to Emmanuel.Duros@udcast.com. -- Hitoshi Asaeda To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 10 4:54:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailout.informatik.tu-muenchen.de (mailout.informatik.tu-muenchen.de [131.159.0.5]) by hub.freebsd.org (Postfix) with ESMTP id B7AA437B408 for ; Fri, 10 May 2002 04:54:50 -0700 (PDT) Received: from mailrelay2.informatik.tu-muenchen.de (mailrelay.informatik.tu-muenchen.de [131.159.2.33]) by mailout.informatik.tu-muenchen.de (Postfix) with ESMTP id 6257A6253; Fri, 10 May 2002 13:54:49 +0200 (MEST) Received: from atrbg11.informatik.tu-muenchen.de (atrbg11.informatik.tu-muenchen.de [131.159.24.91]) by mailrelay2.informatik.tu-muenchen.de (Postfix) with ESMTP id 363BA47386; Fri, 10 May 2002 13:54:49 +0200 (MEST) Received: by atrbg11.informatik.tu-muenchen.de (Postfix, from userid 20455) id 9D528139C8; Fri, 10 May 2002 13:54:48 +0200 (CEST) Date: Fri, 10 May 2002 13:54:48 +0200 From: Daniel Lang To: Nick Rogness Cc: freebsd-net@FreeBSD.ORG Subject: Re: Multiple NICs on the same subnet Message-ID: <20020510115448.GB34132@atrbg11.informatik.tu-muenchen.de> References: <20020509203930.GA32900@atrbg11.informatik.tu-muenchen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-Geek: GCS/CC d-- s: a- C++$ UBS++++$ P+++$ L- E-(---) W+++(--) N++ o K w--- O? M? V? PS+(++) PE--(+) Y+ PGP+ t++ 5+++ X R+(-) tv+ b+ DI++ D++ G++ e+++ h---(-) r++>+++ y+ 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 guess I've found a solution. I'll post it here: Nick Rogness wrote on Thu, May 09, 2002 at 05:28:13PM -0500: [..] > The best way to handle this is with ipfw fwd. Basically you > forward packets trying to leave the default gateway with the > aliased address of a different interface out the right interface. > > For example: > > xl0 --> alias= 1.1.1.1/32 , (default gateway out this interface) > xl1 --> alias= 1.1.1.2/32 > lge0 --> alias= 1.1.1.3/32 > > ipfw ruleset: > > # FOrward packets properly > ipfw fwd $IP_OF_NEXT_HOP_xl1 ip from 1.1.1.2/32 to any out via xl0 > ipfw fwd $IP_OF_NEXT_HOP_lge0 ip from 1.1.1.3/32 to any out via xl0 > . . . [rest of firewall] . . . [..] This did not work, because you cannot specify in the rule which interface to use for the forwarded packet. This is determined by the routing table, as described in ipfw(8). As the $IP_OF_NEXT_HOP_lge0 would be the same for $IP_OF_NEXT_HOP_xl0. So I've used ipfilter instead of ipfw with the following rule: [..] pass out on xl0 fastroute lge0 from 1.1.1.3 to any [..] This matches any packet from 1.1.1.3 which attempts to leave via xl0 but is then stuffed into the outgoing queue of lge0. Again, thanks for your help. Best regards, Daniel -- IRCnet: Mr-Spock - All your .sigs are belong to us - Daniel Lang * dl@leo.org * +49 89 289 25735 * http://www.leo.org/~dl/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 10 5:19:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from hawkins.dropbear.id.au (cu713.adelaide.adsl.on.net [150.101.236.205]) by hub.freebsd.org (Postfix) with ESMTP id 7ADFC37B403 for ; Fri, 10 May 2002 05:19:26 -0700 (PDT) Received: by hawkins.dropbear.id.au (Postfix, from userid 1001) id 9D66C3A555; Fri, 10 May 2002 21:49:24 +0930 (CST) Received: from localhost (localhost [127.0.0.1]) by hawkins.dropbear.id.au (Postfix) with ESMTP id 622643A214 for ; Fri, 10 May 2002 21:49:24 +0930 (CST) Date: Fri, 10 May 2002 21:49:23 +0930 (CST) From: Justin Hawkins X-X-Sender: jhawkins@tardis.everard.bogus To: freebsd-net@freebsd.org Subject: mpd-netgraph as VPN client to Cisco 2500 REDUX Message-ID: <20020510210708.S94900-100000@tardis.everard.bogus> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Well thanks to Archie, I had mpd connecting me to my works 2500 quite successfully. 'Had' being the operative word :-) Unfortunately, the 2500 recently had some configuration changes. Specifically related to the MTU settings. This fixed some other clients, but broke me :-( Symptoms, the connection is initiated and established fine. Some traffic can pass; web access works, but slowly. All ping's fail, I quickly get: From gw.everard.bogus (192.168.0.1): Source Quench From gw.everard.bogus (192.168.0.1): Source Quench From gw.everard.bogus (192.168.0.1): Source Quench From gw.everard.bogus (192.168.0.1): Source Quench for pings. mpd is telling me: [vpn] LCP: no reply to 1 echo request(s) [vpn] LCP: no reply to 2 echo request(s) [vpn] LCP: no reply to 3 echo request(s) [vpn] LCP: no reply to 4 echo request(s) [vpn] LCP: no reply to 5 echo request(s) I'm positive that some traffic does get through - the web accesses I can do would be utterly impossible if it were not for a VPN tunnel (blocked by firewall). The link is effectively unusable though. The cisco config has an MTU of 1524 specified. After I had mpd bring the tunnel up, I manually changed the MTU on ng0 with: ifconfig ng0 mtu 1524 Initially I had limited success with this, pings started working, but web access was worse (non existent). Now I can't even get that. I've tried lower MTU's, to no visible effect. Part of me thinks that if MTU were really a problem, a low MTU (like 300) would fix it, but make performance suck. Perhaps that's not the case. Or perhaps I've misdiagnosed this problem :-) I still have my host route to the cicso via my normal default gateway (because the cisco has an IP on the tunnelled network), and I've upgraded mpd to version 3.8. Any ideas? - Justin -- justin@hawkins.dropbear.id.au | "Don't sweat it -- http://hawkins.dropbear.id.au | it's only 1's and 0's" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 10 5:36:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from hawkins.dropbear.id.au (cu713.adelaide.adsl.on.net [150.101.236.205]) by hub.freebsd.org (Postfix) with ESMTP id BB92337B401 for ; Fri, 10 May 2002 05:35:48 -0700 (PDT) Received: by hawkins.dropbear.id.au (Postfix, from userid 1001) id 213983A555; Fri, 10 May 2002 22:05:47 +0930 (CST) Received: from localhost (localhost [127.0.0.1]) by hawkins.dropbear.id.au (Postfix) with ESMTP id 1E2013A214 for ; Fri, 10 May 2002 22:05:47 +0930 (CST) Date: Fri, 10 May 2002 22:05:46 +0930 (CST) From: Justin Hawkins X-X-Sender: jhawkins@tardis.everard.bogus To: "freebsd-net@freebsd.org" Subject: Re: mpd-netgraph as VPN client to Cisco 2500 REDUX (doh) In-Reply-To: <20020510210708.S94900-100000@tardis.everard.bogus> Message-ID: <20020510220125.A94900-100000@tardis.everard.bogus> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 10 May 2002, Justin Hawkins wrote: > Well thanks to Archie, I had mpd connecting me to my works 2500 quite > successfully. 'Had' being the operative word :-) In the way that only a cry for help on a large mailing list can do, I found the problem myself. It seems that lowering the MTU on the ng0 interface DOES help. I forgot to take NAT out of the equation. There is definately a problem with NAT+VPN, but for the moment I can deal with accessing the VPN networks from only my gateway machine. I actually thought I was bypassing NAT in my web tests. Though the browser is on a NAT'ted machine, it uses a proxy on the gatway to get access... must be something to do with the transparent proxying + NAT + VPN :-) Anyway, now I have a legitimate question, how can I setup mpd to change the MTU on the ng0 interface when it brings it up? - Justin -- justin@hawkins.dropbear.id.au | "Don't sweat it -- http://hawkins.dropbear.id.au | it's only 1's and 0's" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 10 7:36:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 7467E37B400 for ; Fri, 10 May 2002 07:36:16 -0700 (PDT) Received: from keg (c1-vpn3.isi.edu [128.9.176.29]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g4AEaFF11225; Fri, 10 May 2002 07:36:15 -0700 (PDT) From: "Lars Eggert" To: "'Justin Hawkins'" , Subject: RE: mpd-netgraph as VPN client to Cisco 2500 REDUX (doh) Date: Fri, 10 May 2002 07:36:01 -0700 Organization: USC Information Sciences Institute Message-ID: <008701c1f830$022f7db0$b27ba8c0@isi.edu> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 MIME-Version: 1.0 Importance: Normal In-Reply-To: <20020510220125.A94900-100000@tardis.everard.bogus> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0082_01C1F7F5.554A1090" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0082_01C1F7F5.554A1090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > Anyway, now I have a legitimate question, how can I setup mpd > to change the MTU on the ng0 interface when it brings it up? I do this via mpd's "set iface up-script", using a manually chosen MTU. I'd be nice if mpd would do this automatically, based on the MTU of the underlying interface and the length of the encapsulation header... Lars -- Lars Eggert Information Sciences Institute ------=_NextPart_000_0082_01C1F7F5.554A1090 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJFzCCArUw ggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEPMA0GA1UEBBMGRWdnZXJ0 MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFy c2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0AvLBsD78nxcUHeHkaMgl3b4 qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD11uZDy4CNNJUu3gKxKSb+zRV70O+lkwwf tuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcUSF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEA AaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREE ETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQ A8zI7U2K1ZIAl11j0a1DKxnp3GtTvOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2 OhB+jeKEqY7IDAJE4/fI0e+d6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4 fdcOo1S34r4wggMpMIICkqADAgECAgEMMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0 ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQw IgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcNMDIwODI5MjM1OTU5WjCB kjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQD Ex9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y 8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtU ihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp dmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcN AQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kNaiYqYoQfuIdjdBxtt88aU5FL4c3mONnt UPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvBUFe17BzX7xe21Yibt6KIGu05Wzl9NPy2 lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqADAgECAgEAMA0GCSqGSIb3DQEBBAUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24x GjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkq hkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcN MjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRkW3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1 KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZ FKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9edvlWsQcuQIDAQABoxMwETAPBgNVHRMB Af8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O+PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVc CM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyirNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx +NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1RhGvk+NHOd6KBMYIDaTCCA2UCAQEwgZow gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93 bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggIkMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDUxMDE0MzYwMVowIwYJ KoZIhvcNAQkEMRYEFObnSnCinHIcc6aza7x1PgY4E385MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwBwYFKw4DAhowDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMG VGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkG A1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYD VQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJz b25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEBBQAEgYAcBAeuMyWw KBQ4TvPz2NhD7shmQHDhZaumkb5KfSHbgNTOpop9txGfvonbYJUdK5WyoHGeHs/26bqIVb0PgRfF q+eogwQ/mR5rn22MGrAa9k1N8eQavHRLfeTvG9e1kDUAnZVmEKshJzqYOdJn+fxc5hJ4ftVw2m9t UFsQ30UzYgAAAAAAAA== ------=_NextPart_000_0082_01C1F7F5.554A1090-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 10 20:38:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from hm61.locaweb.com.br (hm61.locaweb.com.br [200.213.197.161]) by hub.freebsd.org (Postfix) with SMTP id CDD2037B40D for ; Fri, 10 May 2002 20:38:48 -0700 (PDT) Received: (qmail 11141 invoked from network); 11 May 2002 03:28:39 -0000 Received: from unknown (200.246.179.120) by hm61.locaweb.com.br with QMTP; 11 May 2002 03:28:39 -0000 Received: (qmail 18557 invoked by uid 0); 11 May 2002 03:38:40 -0000 Received: from unknown (HELO wilson) (wilson@quati.com.br@200.181.193.232) by hm20.locaweb.com.br with SMTP; 11 May 2002 03:38:40 -0000 Message-ID: <002301c1f89d$a8ef6620$c8c8a8c0@marcolin.com.br> From: "wilson (quati)" To: Subject: Date: Sat, 11 May 2002 00:40:56 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ------------------------------------------------- Wilson Teles Marcolin Compubras Telecom (45) 572-5000 www.compubras.com.br To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 10 20:45: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 3BBF137B403 for ; Fri, 10 May 2002 20:45:03 -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 UAA43823; Fri, 10 May 2002 20:38:57 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g4B3cqG09077; Fri, 10 May 2002 20:38:52 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200205110338.g4B3cqG09077@arch20m.dellroad.org> Subject: Re: mpd-netgraph as VPN client to Cisco 2500 REDUX (doh) In-Reply-To: <008701c1f830$022f7db0$b27ba8c0@isi.edu> "from Lars Eggert at May 10, 2002 07:36:01 am" To: Lars Eggert Date: Fri, 10 May 2002 20:38:52 -0700 (PDT) Cc: "'Justin Hawkins'" , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Lars Eggert writes: > > Anyway, now I have a legitimate question, how can I setup mpd > > to change the MTU on the ng0 interface when it brings it up? > > I do this via mpd's "set iface up-script", using a manually chosen MTU. > > I'd be nice if mpd would do this automatically, based on the MTU of the > underlying interface and the length of the encapsulation header... Mpd is "supposed" to do this automatically, but it only does it for the PPP headers, not the device headers (such as PPTP/IP/Ethernet). In other words, there is a 'hard' MTU which is the maximum size of a packet you are allowed to send -- which by the way is dictated by (a) the transport layer for your PPP frames (in the case of PPTP, this would be on the order of 65,000 bytes -- because with PPTP the transport for the PPP frame is an IP packet) and (b) what the remote peer asks for (typically 1500 or less), and there is also a 'soft' MTU which is the largest MTU that will not cause any packets to get fragmented at any level along the chain. Mpd only adjusts the interface MTU to handle the 'hard' MTU part. If time permits I'll have it try to be a little smarter. On a related note, you can avoid these problems altogether if you enable multi-link PPP (and the remote PPTP device supports it). With multi-link, PPP packets themselves can be fragmented transparently so the higher layer MTU can be much larger without any ill effects. -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