From owner-freebsd-net Sun Jun 11 0:42:35 2000 Delivered-To: freebsd-net@freebsd.org Received: from obie.softweyr.com (obie.softweyr.com [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id 9DFD637B9FA for ; Sun, 11 Jun 2000 00:42:29 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (Foolstrustident!@homer.softweyr.com [204.68.178.39]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id BAA13735; Sun, 11 Jun 2000 01:42:15 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <394342EF.FE9CA764@softweyr.com> Date: Sun, 11 Jun 2000 01:42:39 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: CyberSniper Cc: freebsd-net@FreeBSD.ORG Subject: Re: Off topic, sorta: home RJ-45 wiring References: <200006011642.MAA22594@larryboy.graphics.cornell.edu> <3936EB42.D53D001C@softweyr.com> <20000610145041.F63030@ethereal.net> <002901bfd359$f0d53d40$02000a0a@wrath01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org CyberSniper wrote: > > the kit to do it: > http://www2.warehouse.com/product.asp?pf%5Fid=DTK1462&blind=no&cat=datacomm > > extra wire in case you're running wire to the moon: > http://www2.warehouse.com/product.asp?pf%5Fid=DBC1838 > > you'll also need to acquire an outlet/switch box for each wallplate, a 3/8" > drill and a 3/8" to 1/2" paddle bit to drill the holes. if you bought some > phone wire/video wire/cat5 staples it'd look more professional. you can do > all of it with time and a little ingenuity, especially since you have a > crawlspace and an attic to work in. > > i've never seen an electrician that was qualified to run data cables step in > a house for under $500. > > some things to consider: > don't coil excess wire. > don't kink or run a staple through the wire(if you bother to secure it). > keep wire atleast four inches away from power lines Make it a foot, just to be sure. When you cross power lines, cross at 90 degrees. > keep wire atleast eight inches away from transformers like doorbell > transformers and fluorescent light ballasts. > > someone mentioned a site that explains how to terminate a pass through and a > cross cable. maybe they could repost? The only pass-through I've ever used is a 1/4" drill bit 14" long. Drill all the way through the wall, being careful to avoid power wires, remove the drill motor from the bit, tape the cable to the end of the drill bit with masking tape, and pull the cable through. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 11 3:10:53 2000 Delivered-To: freebsd-net@freebsd.org Received: from pooh.aist-nara.ac.jp (inet1.aist-nara.ac.jp [163.221.52.121]) by hub.freebsd.org (Postfix) with ESMTP id 1CD2737BF58 for ; Sun, 11 Jun 2000 03:10:48 -0700 (PDT) (envelope-from demizu@dd.iij4u.or.jp) Received: from localhost by pooh.aist-nara.ac.jp (8.8.7/2.8Wb) id KAA06427; Sun, 11 Jun 2000 10:10:54 GMT From: Noritoshi Demizu To: freebsd-net@freebsd.org Subject: Re: RFC 2140 In-Reply-To: Your message of "Wed, 22 Dec 1999 02:27:10 +0900" References: <19991222022710N.demizu@dd.iij4u.or.jp> X-Mailer: Mew version 1.69 on Emacs 19.28.1 / Mule 2.3 X-URL: http://infonet.aist-nara.ac.jp/member/nori-d/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000611191053A.demizu@dd.iij4u.or.jp> Date: Sun, 11 Jun 2000 19:10:53 +0900 X-Dispatcher: impost version 0.99i (Apr. 6, 1997) Lines: 17 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > We have been modifying TCP code of FreeBSD 3.2R to support RFC2140. Our experimental code has been ported to 3.4R and is available at: http://landwalker.aist-nara.ac.jp/tcp-ikoma/ Our code is running on this machine. Through our experiments, our code seems to be slightly robust against random packet loss. The Time-Sequence Graphs of our experiments can be viewed at the above page. (I hope it's not due to our bug...) Sorry, No English document is available at this moment. Thank you. Noritoshi Demizu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 11 3:46:29 2000 Delivered-To: freebsd-net@freebsd.org Received: from game.over.net (game.over.net [193.189.189.100]) by hub.freebsd.org (Postfix) with ESMTP id 3187737BF9A for ; Sun, 11 Jun 2000 03:46:12 -0700 (PDT) (envelope-from tomaz.borstnar@over.net) Received: from [212.30.94.31] ([212.30.94.31]:13607 "EHLO user.over.net") by mail.over.net with ESMTP id ; Sun, 11 Jun 2000 12:45:56 +0200 Message-Id: <4.3.2.7.2.20000611123000.02f52100@193.189.189.100> X-Sender: tmail@193.189.189.100 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 11 Jun 2000 12:39:57 -0100 To: freebsd-net@freebsd.org From: Tomaz Borstnar Subject: multilink PPPoE possible? and nortel shasta 5000 problems In-Reply-To: <20000524193236.A64820@myriade.laissus.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is it possible to run 2 PPPoE sessions to provider and do NAT for internal net so everything works? With just one connection I can't utilize enough of bandwidth and my provider is letting me use 2 logins per username. Btw: Anyone here connected with FreeBSD's pppoe client to Nortel Shasta 5000? I'm having problems with this setup - lots of messages like this: May 25 10:07:08 triglav ppp[1287]: tun0: Warning: deflink: Oops: Got 58 bytes but 10 byte payload They're running firmware 1.5.10 there. Log is like this: May 25 10:07:05 triglav ppp[1286]: Phase: Using interface: tun0 May 25 10:07:05 triglav ppp[1286]: Phase: deflink: Created in closed state May 25 10:07:05 triglav ppp[1286]: tun0: Command: default: nat enable yes May 25 10:07:05 triglav ppp[1286]: tun0: Command: default: nat same_ports yes May 25 10:07:05 triglav ppp[1286]: tun0: Command: default: nat use_sockets yes May 25 10:07:05 triglav ppp[1286]: tun0: Command: default: set redial 15 28800 May 25 10:07:05 triglav ppp[1286]: tun0: Command: default: set reconnect 15 28800 May 25 10:07:05 triglav ppp[1286]: tun0: Command: pppoe: set device PPPoE:ed1: May 25 10:07:05 triglav ppp[1286]: tun0: Command: pppoe: set mru 1492 May 25 10:07:05 triglav ppp[1286]: tun0: Command: pppoe: set mtu 1492 May 25 10:07:05 triglav ppp[1286]: tun0: Command: pppoe: set speed sync May 25 10:07:05 triglav ppp[1286]: tun0: Command: pppoe: set cd 5 May 25 10:07:05 triglav ppp[1286]: tun0: Command: pppoe: set dial May 25 10:07:05 triglav ppp[1286]: tun0: Command: pppoe: set login May 25 10:07:05 triglav ppp[1286]: tun0: Command: pppoe: set timeout 0 May 25 10:07:05 triglav ppp[1286]: tun0: Command: pppoe: set authname mibo9 May 25 10:07:05 triglav ppp[1286]: tun0: Command: pppoe: set authkey ******** May 25 10:07:05 triglav ppp[1286]: tun0: Command: pppoe: set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 May 25 10:07:05 triglav ppp[1286]: tun0: Command: pppoe: add default HISADDR May 25 10:07:05 triglav ppp[1287]: tun0: Phase: PPP Started (ddial mode). May 25 10:07:05 triglav ppp[1287]: tun0: Phase: bundle: Establish May 25 10:07:05 triglav ppp[1287]: tun0: Phase: deflink: closed -> opening May 25 10:07:05 triglav ppp[1287]: tun0: Phase: deflink: Connected! May 25 10:07:05 triglav ppp[1287]: tun0: Phase: deflink: opening -> dial May 25 10:07:05 triglav ppp[1287]: tun0: Phase: deflink: dial -> carrier May 25 10:07:06 triglav ppp[1287]: tun0: Phase: Received NGM_PPPOE_SUCCESS (hook "tun0") May 25 10:07:06 triglav ppp[1287]: tun0: Phase: deflink: carrier -> login May 25 10:07:06 triglav ppp[1287]: tun0: Phase: deflink: login -> lcp May 25 10:07:07 triglav ppp[1287]: tun0: Warning: deflink: Oops: Got 58 bytes but 19 byte payload May 25 10:07:07 triglav ppp[1287]: tun0: Warning: deflink: Oops: Got 58 bytes but 14 byte payload May 25 10:07:07 triglav ppp[1287]: tun0: Phase: bundle: Authenticate May 25 10:07:07 triglav ppp[1287]: tun0: Phase: deflink: his = CHAP 0x05, mine = none May 25 10:07:07 triglav ppp[1287]: tun0: Phase: Chap Input: CHALLENGE (16 bytes from ppp@shastanets.com) May 25 10:07:07 triglav ppp[1287]: tun0: Phase: Chap Output: RESPONSE (mibo9) May 25 10:07:07 triglav ppp[1287]: tun0: Phase: Chap Input: SUCCESS May 25 10:07:07 triglav ppp[1287]: tun0: IPCP: Using trigger address 0.0.0.0 May 25 10:07:07 triglav ppp[1287]: tun0: CCP: FSM: Using "deflink" as a transport May 25 10:07:08 triglav ppp[1287]: tun0: CCP: deflink: State change Initial --> Closed May 25 10:07:08 triglav ppp[1287]: tun0: CCP: deflink: LayerStart. May 25 10:07:08 triglav ppp[1287]: tun0: CCP: deflink: SendConfigReq(1) state = Closed May 25 10:07:08 triglav ppp[1287]: tun0: CCP: DEFLATE[4] win 15 May 25 10:07:08 triglav ppp[1287]: tun0: CCP: PRED1[2] May 25 10:07:08 triglav ppp[1287]: tun0: CCP: deflink: State change Closed --> Req-Sent May 25 10:07:08 triglav ppp[1287]: tun0: Phase: deflink: lcp -> open May 25 10:07:08 triglav ppp[1287]: tun0: Phase: bundle: Network May 25 10:07:08 triglav ppp[1287]: tun0: IPCP: FSM: Using "deflink" as a transport May 25 10:07:08 triglav ppp[1287]: tun0: IPCP: deflink: State change Initial --> Closed May 25 10:07:08 triglav ppp[1287]: tun0: IPCP: deflink: LayerStart. May 25 10:07:08 triglav ppp[1287]: tun0: IPCP: deflink: SendConfigReq(1) state = Closed May 25 10:07:08 triglav ppp[1287]: tun0: IPCP: IPADDR[6] 0.0.0.0 May 25 10:07:08 triglav ppp[1287]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression May 25 10:07:08 triglav ppp[1287]: tun0: IPCP: deflink: State change Closed --> Req-Sent May 25 10:07:08 triglav ppp[1287]: tun0: Warning: deflink: Oops: Got 58 bytes but 10 byte payload May 25 10:07:08 triglav ppp[1287]: tun0: IPCP: deflink: RecvConfigReq(15) state = Req-Sent May 25 10:07:08 triglav ppp[1287]: tun0: IPCP: IPADDR[6] 193.189.161.74 May 25 10:07:08 triglav ppp[1287]: tun0: IPCP: deflink: SendConfigAck(15) state = Req-Sent May 25 10:07:08 triglav ppp[1287]: tun0: IPCP: IPADDR[6] 193.189.161.74 May 25 10:07:08 triglav ppp[1287]: tun0: IPCP: deflink: State change Req-Sent --> Ack-Sent May 25 10:07:08 triglav ppp[1287]: tun0: Warning: deflink: Oops: Got 58 bytes but 44 byte payload May 25 10:07:08 triglav ppp[1287]: tun0: CCP: deflink: State change Req-Sent --> Stopped May 25 10:07:08 triglav ppp[1287]: tun0: Warning: deflink: Oops: Got 58 bytes but 10 byte payload May 25 10:07:08 triglav ppp[1287]: tun0: IPCP: deflink: RecvConfigRej(1) state = Ack-Sent May 25 10:07:08 triglav ppp[1287]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression May 25 10:07:08 triglav ppp[1287]: tun0: IPCP: deflink: SendConfigReq(2) state = Ack-Sent May 25 10:07:08 triglav ppp[1287]: tun0: IPCP: IPADDR[6] 0.0.0.0 May 25 10:07:08 triglav ppp[1287]: tun0: Warning: deflink: Oops: Got 58 bytes but 10 byte payload May 25 10:07:08 triglav ppp[1287]: tun0: IPCP: deflink: RecvConfigNak(2) state = Ack-Sent May 25 10:07:08 triglav ppp[1287]: tun0: IPCP: IPADDR[6] 213.250.60.193 May 25 10:07:08 triglav ppp[1287]: tun0: IPCP: IPADDR[6] changing address: 0.0.0.0 --> 213.250.60.193 May 25 10:07:08 triglav ppp[1287]: tun0: IPCP: deflink: SendConfigReq(3) state = Ack-Sent May 25 10:07:08 triglav ppp[1287]: tun0: IPCP: IPADDR[6] 213.250.60.193 May 25 10:07:08 triglav ppp[1287]: tun0: Warning: deflink: Oops: Got 58 bytes but 10 byte payload May 25 10:07:08 triglav ppp[1287]: tun0: IPCP: deflink: RecvConfigAck(3) state = Ack-Sent May 25 10:07:08 triglav ppp[1287]: tun0: IPCP: deflink: State change Ack-Sent --> Opened May 25 10:07:08 triglav ppp[1287]: tun0: IPCP: deflink: LayerUp. May 25 10:07:08 triglav ppp[1287]: tun0: IPCP: myaddr 213.250.60.193 hisaddr = 193.189.161.74 May 25 10:07:18 triglav ppp[1287]: tun0: Warning: deflink: Oops: Got 58 bytes but 8 byte payload May 25 10:07:51 triglav last message repeated 3 times May 25 10:09:51 triglav last message repeated 11 times May 25 10:14:45 triglav last message repeated 27 times May 25 10:14:50 triglav ppp[1287]: tun0: Phase: Signal 1, terminate. May 25 10:14:50 triglav ppp[1287]: tun0: IPCP: deflink: LayerDown: 213.250.60.193 May 25 10:14:50 triglav ppp[1287]: tun0: IPCP: Using trigger address 0.0.0.0 May 25 10:14:50 triglav ppp[1287]: tun0: IPCP: deflink: SendTerminateReq(4) state = Opened May 25 10:14:50 triglav ppp[1287]: tun0: IPCP: deflink: State change Opened --> Closing May 25 10:14:50 triglav ppp[1287]: tun0: Warning: deflink: Oops: Got 58 bytes but 4 byte payload May 25 10:14:50 triglav ppp[1287]: tun0: IPCP: deflink: RecvTerminateAck(4) state = Closing May 25 10:14:50 triglav ppp[1287]: tun0: IPCP: deflink: LayerFinish. May 25 10:14:50 triglav ppp[1287]: tun0: IPCP: Connect time: 462 secs: 3731338 octets in, 61154 octets out May 25 10:14:50 triglav ppp[1287]: tun0: IPCP: total 8208 bytes/sec, peak 34739 bytes/sec on Thu May 25 10:14:50 2000 May 25 10:14:50 triglav ppp[1287]: tun0: IPCP: deflink: State change Closing --> Closed May 25 10:14:50 triglav ppp[1287]: tun0: Phase: bundle: Terminate May 25 10:14:50 triglav ppp[1287]: tun0: CCP: deflink: State change Stopped --> Closed May 25 10:14:50 triglav ppp[1287]: tun0: CCP: deflink: State change Closed --> Initial May 25 10:14:50 triglav ppp[1287]: tun0: Phase: deflink: open -> lcp May 25 10:14:50 triglav ppp[1287]: tun0: IPCP: deflink: State change Closed --> Initial May 25 10:14:50 triglav ppp[1287]: tun0: Warning: deflink: Oops: Got 58 bytes but 4 byte payload May 25 10:14:50 triglav ppp[1287]: tun0: Phase: deflink: Disconnected! May 25 10:14:50 triglav ppp[1287]: tun0: Phase: deflink: lcp -> logout May 25 10:14:50 triglav ppp[1287]: tun0: Phase: deflink: logout -> hangup May 25 10:14:50 triglav ppp[1287]: tun0: Phase: deflink: Disconnected! May 25 10:14:50 triglav ppp[1287]: tun0: Phase: deflink: Connect time: 465 secs: 3741984 octets in, 64239 octets out May 25 10:14:50 triglav ppp[1287]: tun0: Phase: total 8185 bytes/sec, peak 34835 bytes/sec on Thu May 25 10:14:50 2000 May 25 10:14:50 triglav ppp[1287]: tun0: Phase: deflink: hangup -> closed May 25 10:14:50 triglav ppp[1287]: tun0: Phase: bundle: Dead May 25 10:14:50 triglav ppp[1287]: tun0: Phase: PPP Terminated (normal). I can never go over 70KB/s! Mostly it is limited to 62 to 65KB/s while NTS's Enternet client can go to around 80 KB/s. Tomaz ---- Tomaz Borstnar "Love is the answer to the final question you ask" - Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 11 4: 5:40 2000 Delivered-To: freebsd-net@freebsd.org Received: from game.over.net (game.over.net [193.189.189.100]) by hub.freebsd.org (Postfix) with ESMTP id C460237B985 for ; Sun, 11 Jun 2000 04:05:35 -0700 (PDT) (envelope-from tomaz.borstnar@over.net) Received: from [212.30.94.31] ([212.30.94.31]:14119 "EHLO user.over.net") by mail.over.net with ESMTP id ; Sun, 11 Jun 2000 13:05:16 +0200 Message-Id: <4.3.2.7.2.20000611130210.02f519e0@193.189.189.100> X-Sender: tmail@193.189.189.100 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 11 Jun 2000 13:05:12 -0100 To: freebsd-net@freebsd.org From: Tomaz Borstnar Subject: tun0 limited to14.4KB/s according to mrtg? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello! MRTG's cfgmaker thinks tun0's bandwidth is limited to 14.4KB/s and graphs show that. But this is weird since I use tun0 for PPPoE and it surely goes faster than that. Any idea how to properly use mrtg for graphing PPPoE throughput? Provider assigns new ip at every connect. Thanks in advance. Tomaz ---- Tomaz Borstnar "Love is the answer to the final question you ask" - Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 11 5:19:41 2000 Delivered-To: freebsd-net@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id D307A37BF97 for ; Sun, 11 Jun 2000 05:19:35 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (hak.nat.Awfulhak.org [172.31.0.12]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id NAA27496; Sun, 11 Jun 2000 13:19:33 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id NAA01495; Sun, 11 Jun 2000 13:19:30 +0100 (BST) (envelope-from brian@Awfulhak.org) Message-Id: <200006111219.NAA01495@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Tomaz Borstnar Cc: freebsd-net@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: multilink PPPoE possible? and nortel shasta 5000 problems In-Reply-To: Message from Tomaz Borstnar of "Sun, 11 Jun 2000 12:39:57 -0100." <4.3.2.7.2.20000611123000.02f52100@193.189.189.100> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 11 Jun 2000 13:19:29 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Is it possible to run 2 PPPoE sessions to provider and do NAT for internal > net so everything works? With just one connection I can't utilize enough of > bandwidth and my provider is letting me use 2 logins per username. There should be no problem. Have they set up MP on the other end so that you can multi-link the two and get two pieces of pie ? If not, you're just going to have a routing fiasco. > Btw: Anyone here connected with FreeBSD's pppoe client to Nortel Shasta > 5000? I'm having problems with this setup - lots of messages like this: > > > May 25 10:07:08 triglav ppp[1287]: tun0: Warning: deflink: Oops: Got 58 > bytes but 10 byte payload > > > They're running firmware 1.5.10 there. [.....] I've just read the specs, and figured out that this is actually a (harmless) bug in ppp. I recently added it thinking that I was adding an extra consistency check, but instead I'm complaining about completely legal padding characters. Fixing it now..... > Tomaz > ---- > Tomaz Borstnar > "Love is the answer to the final question you ask" - Unknown -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 11 6: 7:27 2000 Delivered-To: freebsd-net@freebsd.org Received: from netcom.com (netcom9.netcom.com [199.183.9.109]) by hub.freebsd.org (Postfix) with ESMTP id C35BA37B7BD for ; Sun, 11 Jun 2000 06:07:20 -0700 (PDT) (envelope-from stanb@netcom.com) Received: (from stanb@localhost) by netcom.com (8.9.3/8.9.3) id GAA06983 for freebsd-net@FreeBSD.ORG; Sun, 11 Jun 2000 06:05:16 -0700 (PDT) From: Stan Brown Message-Id: <200006111305.GAA06983@netcom.com> Subject: Differences between FreeBSD NAt & OpneBSD BAT? To: freebsd-net@FreeBSD.ORG (FreeBSD Networking) Date: Sun, 11 Jun 2000 09:05:16 -0400 (EDT) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have been using a FreeBSD machine as my Firewall/NAT machine between my home network, and the internet for years. Grist wit dialup ppp, and now with cableModem. because of the fixed IP address, and the huge amount of break in atempts that I am seeinng on i, I am serioulsy considering replacing this machien with an OpenBSD machine. The theory being that the "secure by default" philosophy will protect me in areas where I may not quie know what I am doing. I have read the OpenBSD networking setup information, and most of it appears to be comparable. The firewall rules work pretty difernly bu default, but I think I understand the differences here. The real question is in NAT. I have used the FreeBSD version(s) for _years_ and they have been virtualy transparent to me. As far as I can recall the _only_ visible difference to the machiens on my network, has been haiving to use passive mode CVSUP. It appears as though this is not the case with the OpenBSD NAT. It looks as though I have to explciitly "proxy" for services that use non well known ports. Since there is usaually a great deal fo cross-polenation between the various *BSD tress, I figure someone on this lis could probably give me an explanation of the differences here? Why are thet different? How will the differences affect me as a user? What do I need to do to make the OpenBSD NAT work as closely as possible to the FreeBSD NAT? Is therw a security implication of doing this? Thansk for the feedback on this. Oh, BTW, I am still deploying lot's of FreeeBSD machines, it's jsut That I have the feeling this particular appplication is better suited to OpneBSD, given my less than total expertise at dealing with what is clearly becomeing quite a hostile world out there. If anyonewants to try to cinvince me otherwaise, I would be willing to listen. -- Stan Brown stanb@netcom.com 404-996-6955 Factory Automation Systems Atlanta Ga. -- Look, look, see Windows 95. Buy, lemmings, buy! Pay no attention to that cliff ahead... Henry Spencer (c) 1998 Stan Brown. Redistribution via the Microsoft Network is prohibited. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 11 6:29:45 2000 Delivered-To: freebsd-net@freebsd.org Received: from game.over.net (game.over.net [193.189.189.100]) by hub.freebsd.org (Postfix) with ESMTP id C347137B8CB for ; Sun, 11 Jun 2000 06:29:42 -0700 (PDT) (envelope-from tomaz.borstnar@over.net) Received: from [212.30.94.31] ([212.30.94.31]:1833 "EHLO user.over.net") by mail.over.net with ESMTP id ; Sun, 11 Jun 2000 15:29:27 +0200 Message-Id: <4.3.2.7.2.20000611152508.02e6a100@193.189.189.100> X-Sender: tmail@193.189.189.100 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 11 Jun 2000 15:29:07 -0100 To: freebsd-net@FreeBSD.ORG From: Tomaz Borstnar Subject: Re: multilink PPPoE possible? and nortel shasta 5000 problems In-Reply-To: <200006111219.NAA01495@hak.lan.Awfulhak.org> References: <4.3.2.7.2.20000611123000.02f52100@193.189.189.100> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 11:19 AM 11/06/00, Brian Somers wrote the following message: > > Is it possible to run 2 PPPoE sessions to provider and do NAT for internal > > net so everything works? With just one connection I can't utilize > enough of > > bandwidth and my provider is letting me use 2 logins per username. >There should be no problem. Have they set up MP on the other end so >that you can multi-link the two and get two pieces of pie ? If not, >you're just going to have a routing fiasco. Probably not. I'll ask anyway, but if they don't support it then I'm out of luck to squeeze more from the connection? I noticed that without "Log on to network" option in Entera client I can't login to Shasta. Would some missing option limit speed of my connection as I'm not able to achieve similar speed as Windows pppoe client from NTS (Entera). Tomaz ---- Tomaz Borstnar "Love is the answer to the final question you ask" - Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 11 7:32:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from netcom.com (netcom18.netcom.com [199.183.9.118]) by hub.freebsd.org (Postfix) with ESMTP id F170737B93A for ; Sun, 11 Jun 2000 07:32:14 -0700 (PDT) (envelope-from stanb@netcom.com) Received: (from stanb@localhost) by netcom.com (8.9.3/8.9.3) id HAA19429 for freebsd-net@FreeBSD.ORG; Sun, 11 Jun 2000 07:30:26 -0700 (PDT) From: Stan Brown Message-Id: <200006111430.HAA19429@netcom.com> Subject: Why am I getting this error message? To: freebsd-net@FreeBSD.ORG (FreeBSD Networking) Date: Sun, 11 Jun 2000 10:30:26 -0400 (EDT) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am getting the following error message on one of my 3.4 STABLE boxes for som, but bot all machines runing rwhod: Jun 11 10:31:14 koala.fas.com rwhod[247]: whod.brown: Permission denied What do I have misconfigured? -- Stan Brown stanb@netcom.com 404-996-6955 Factory Automation Systems Atlanta Ga. -- Look, look, see Windows 95. Buy, lemmings, buy! Pay no attention to that cliff ahead... Henry Spencer (c) 1998 Stan Brown. Redistribution via the Microsoft Network is prohibited. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 11 10:50:10 2000 Delivered-To: freebsd-net@freebsd.org Received: from vortex.greycat.com (vortex.greycat.com [207.173.133.4]) by hub.freebsd.org (Postfix) with SMTP id F1C8C37B7E4 for ; Sun, 11 Jun 2000 10:50:04 -0700 (PDT) (envelope-from dann@greycat.com) Received: (qmail 11580 invoked from network); 11 Jun 2000 17:50:01 -0000 Received: from bigphred.greycat.com (HELO greycat.com) (207.173.133.2) by vortex.greycat.com with SMTP; 11 Jun 2000 17:50:01 -0000 Received: (from dann@localhost) by greycat.com (8.9.3/8.9.3) id KAA08920 for net@freebsd.org; Sun, 11 Jun 2000 10:50:00 -0700 (PDT) (envelope-from dann) Date: Sun, 11 Jun 2000 10:50:00 -0700 From: Dann Lunsford To: net@freebsd.org Subject: Strange MTU related (?) problem Message-ID: <20000611105000.A7581@greycat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi. Running 4.0-STABLE as of 28-May-2000. Box is a DFI K6-II 350 mobo with 256M. Ethercard is a 3c509B (ep driver). Box is on my home LAN with a mix of other OS'es (Linux, OS/2, VAX/VMS, NetBSD/VAX, No MS stuff :-) ), behind a Linux box (soon to be replaced with a FreeBSD box) acting as router and firewall. Anyway, a couple of days ago, something wierd started happening: I stopped being able to access certain websites, notably (!) slashdot.org. Doesn't matter what machine I come from, or what browser (lynx, netscape, hotjava, or a hack using netcat as a backend), the same thing happens: Enter URL, see the browser specific "connected to ..." message and then ... nothing. Have waited for 6-7 minutes, just to see what happens. Tcpdump shows the tcp 3-way handshake, my brower sending initial GET, the ACK for the GET, and then the connection just sits there. NO packets at all, till I stop it, and then I see the FIN_ACK, FIN pair for a normal close. This behavior has been observed before, when my ISP had put a Foundry level 3 switch in and was using it to divert web traffic to a squid. I protested, and they re-arranged things so my net connection went to the other side of the switch. Problem solved. I called my ISP and was told by an old friend who works there (that's one reason they're my ISP :-) ) that they were no longer doing that; way too many problems. He also checked and found that my connection was still direct into the main router. So that's not it. I started playing with traceroute, nmap, etc. Nothing obvious; the last few hops to slashdot.org were blotto, but with so many idiots blocking ICMP indiscriminately, that wasn't surprising. Then I realized that path MTU discovery depended on ICMP, so I started playing with the MTU on this box. BINGO! Any MTU larger than 1024 (extremely suspicious number, I think!), slashdot not accessible; 1024 or smaller, everything OK. Turning net.inet.tcp.path_mtu_discovery on or off had no effect, Now this is a solution to the immediate problem, But it irritates me greatly because, among other things, it affects my LAN performance, So, questions: Anybody else see this sort of behavior, and, is there any way to pinpoint what machine is doing this so polite letters can be written to the responsible parties (Packages with high explosives are not an option; much too messy :-) ) ? Thanks! -- Dann Lunsford The only thing necessary for the triumph of evil dann@greycat.com is that men of good will do nothing. -- Cicero To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 11 11:24:25 2000 Delivered-To: freebsd-net@freebsd.org Received: from alive.znep.com (alive.znep.com [207.167.15.58]) by hub.freebsd.org (Postfix) with ESMTP id C0ACD37B8FD for ; Sun, 11 Jun 2000 11:24:18 -0700 (PDT) (envelope-from marcs@znep.com) Received: from localhost (marcs@localhost) by alive.znep.com (8.9.3/8.9.1) with ESMTP id MAA65898; Sun, 11 Jun 2000 12:24:05 -0600 (MDT) (envelope-from marcs@znep.com) Date: Sun, 11 Jun 2000 12:24:05 -0600 (MDT) From: Marc Slemko To: Dann Lunsford Cc: net@FreeBSD.ORG Subject: Re: Strange MTU related (?) problem In-Reply-To: <20000611105000.A7581@greycat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 11 Jun 2000, Dann Lunsford wrote: > I started playing with traceroute, nmap, etc. Nothing obvious; the last > few hops to slashdot.org were blotto, but with so many idiots blocking > ICMP indiscriminately, that wasn't surprising. Then I realized that path > MTU discovery depended on ICMP, so I started playing with the MTU on > this box. BINGO! Any MTU larger than 1024 (extremely suspicious number, > I think!), slashdot not accessible; 1024 or smaller, everything OK. > Turning net.inet.tcp.path_mtu_discovery on or off had no effect, Yup, because it is the remote end that is the problem. (oh, and before I get my rant going I should mention http://users.worldgate.com/~marcs/mtu/ which contains an overview of the general PMTU-D horkage issue for people not familiar with it) > Now this is a solution to the immediate problem, But it irritates me greatly > because, among other things, it affects my LAN performance, So, questions: > Anybody else see this sort of behavior, and, is there any way to pinpoint > what machine is doing this so polite letters can be written to the > responsible parties (Packages with high explosives are not an option; much > too messy :-) ) ? Well, there are two possible ways to avoid it. First, somewhere between you and them there is a link with a MTU smaller than the MTU of your local interface. Normally, this link is closer to you than them. So you can work around it by making sure that none of the links close to you have a MTU smaller than your systems do. This assumes, of course, they are using ethernet and not something with a bigger MTU that makes this impractical. That is still just a workaround though, however it often makes sense for other reasons anyway. Most networks have a setup like this workaround suggests, which is why they don't run into the problem. Second, the problem is likely with slashdot's load balancing system. I haven't used the Arrowpoint load balancer that slashdot is using, but in my experience most load balancers are too braindead to properly deal with PMTU-D because the people writing code for them often barely understand what TCP is. What they need to do is, when they get an ICMP can't fragment message, is send it to _all_ the backend boxes (well, they can narrow that down a bit if they take extra pains, but it isn't necessarily worth it). Cisco's local director pile of junk doesn't. F5's bigips don't (well, supposedly they do now after a big stink was raised on nanog about how they broke whois, but I haven't seen it in action yet and they certainly refused to fix it a year or so before that incident, when we complained). I would not be at all suprised if the Arrowpoint doesn't either. The general rule is that if you have systems behind a load balancer, you must disable PMTU-D on them unless you are positive that your load balancer handles it properly. Ten to one, that is the problem here. It could be elsewhere, but it isn't as likely. I can tell you that the www.slashdot.org web servers do have PMTU-D enabled. It isn't clear why this suddenly started happening for you. Perhaps there was some change closer to your end of the world that either increased the MTU on your systems or decreased the MTU of some link. Or perhaps slashdot did really change something recently. I suppose it is also possible that something in the path between you and them started blocking ICMP can't fragment messages. In any case, the proper fix is probably to complain to slashdot and tell them to fix their probably broken systems. Unfortunately, without access to both ends, determining if that is the case for sure isn't easy. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 11 11:29:33 2000 Delivered-To: freebsd-net@freebsd.org Received: from alive.znep.com (alive.znep.com [207.167.15.58]) by hub.freebsd.org (Postfix) with ESMTP id 5362137B8FD for ; Sun, 11 Jun 2000 11:29:31 -0700 (PDT) (envelope-from marcs@znep.com) Received: from localhost (marcs@localhost) by alive.znep.com (8.9.3/8.9.1) with ESMTP id MAA65935; Sun, 11 Jun 2000 12:29:21 -0600 (MDT) (envelope-from marcs@znep.com) Date: Sun, 11 Jun 2000 12:29:21 -0600 (MDT) From: Marc Slemko To: Dann Lunsford Cc: net@FreeBSD.ORG Subject: Re: Strange MTU related (?) problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 11 Jun 2000, Marc Slemko wrote: > In any case, the proper fix is probably to complain to slashdot and tell > them to fix their probably broken systems. Unfortunately, without access > to both ends, determining if that is the case for sure isn't easy. Well, I just reproduced the same thing on my test setup here by lowering the MTU on the router in the middle, so it looks like it is almost certainly near slashdot's end, probably with their load balancers. So I'm going to drop a note to them asking them to smarten up... As for the general case, education is the only answer. People need to understand that ICMP matters, and that TCP is complex and you need chimps to work on it, not mere monkeys. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 11 21:50:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from pail.ircache.net (pail.scd.ucar.edu [128.117.28.5]) by hub.freebsd.org (Postfix) with ESMTP id 58FC337B524 for ; Sun, 11 Jun 2000 21:50:13 -0700 (PDT) (envelope-from rousskov@ircache.net) Received: from localhost (rousskov@localhost) by pail.ircache.net (8.9.2/8.8.7) with ESMTP id WAA17742; Sun, 11 Jun 2000 22:50:06 -0600 (MDT) (envelope-from rousskov@ircache.net) Date: Sun, 11 Jun 2000 22:50:06 -0600 (MDT) From: Alex Rousskov To: Bruce Evans Cc: freebsd-net@FreeBSD.ORG Subject: Re: corrupted poll(2) results? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 10 Jun 2000, Bruce Evans wrote: > On Fri, 9 Jun 2000, Alex Rousskov wrote: > > > Can anybody offer any insight? Is there anything that can make poll fail when > > more than 4K FDs are in use? > > There is a possibly-related kernel bug in FreeBSD-3.3. It sometimes > corrupts kernel fd tables and causes the whole kernel to fail. It is > sometimes activated by allocating lots of fd's and forking and exiting > in a child process. See PRi 16568. Upgrade to FreeBSD-stable (3.x > after 3.4-release) yesterday. Bruce, Thanks a lot for the tip! Applying the patch from PR 16568 fixed the bug. Will sync with the stable branch... Alex. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 11 22: 9:59 2000 Delivered-To: freebsd-net@freebsd.org Received: from vortex.greycat.com (vortex.greycat.com [207.173.133.4]) by hub.freebsd.org (Postfix) with SMTP id B0DA437B943 for ; Sun, 11 Jun 2000 22:09:52 -0700 (PDT) (envelope-from dann@greycat.com) Received: (qmail 13371 invoked from network); 12 Jun 2000 05:09:49 -0000 Received: from bigphred.greycat.com (HELO greycat.com) (207.173.133.2) by vortex.greycat.com with SMTP; 12 Jun 2000 05:09:49 -0000 Received: (from dann@localhost) by greycat.com (8.9.3/8.9.3) id WAA47816 for net@freebsd.org; Sun, 11 Jun 2000 22:09:44 -0700 (PDT) (envelope-from dann) Date: Sun, 11 Jun 2000 22:09:44 -0700 From: Dann Lunsford To: net@freebsd.org Subject: Re: Strange MTU related (?) problem Message-ID: <20000611220944.A47466@greycat.com> References: <20000611105000.A7581@greycat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from marcs@znep.com on Sun, Jun 11, 2000 at 12:24:05PM -0600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Jun 11, 2000 at 12:24:05PM -0600, Marc Slemko wrote: > On Sun, 11 Jun 2000, Dann Lunsford wrote: > > > Turning net.inet.tcp.path_mtu_discovery on or off had no effect, > > Yup, because it is the remote end that is the problem. I thought it might operate by turning off the DF bit. Looking at the code and traces, it apparently doesn't. To tell the truth, I'm not exactly sure what it *does* do :-), but I was in a massive "what the hell" sort of mood. > > (oh, and before I get my rant going I should mention > http://users.worldgate.com/~marcs/mtu/ which contains an overview > of the general PMTU-D horkage issue for people not familiar with > it) Very nice explanation. Now if only we could make reading and understanding the implications a prerequisite for anyone mucking with filters... Your suggestions were cogent, but unfortunately the only systems I have control over are the ones in this house. The complaint about stupidly designed load-balancers echoes one I have about software written in this day and age that doesn't consider security issues (buffer overflows being the most common flaw in *new* software). *sigh* "Against stupidity, the gods themselves contend in vain." It was true when von Schiller wrote it, it remains true today. > > It isn't clear why this suddenly started happening for you. Perhaps there > was some change closer to your end of the world that either increased the > MTU on your systems or decreased the MTU of some link. Or perhaps > slashdot did really change something recently. I suppose it is also > possible that something in the path between you and them started blocking > ICMP can't fragment messages. > I hadn't changed anything here, and my friend who works at my ISP assures me they hadn't changed anything. I did notice that traceroute starts "*"ing its probes at an address *very* close to slashdot, though; slashdot is 64.28.67.48, and the last hop that traceroute shows before starting timeouts is 64.28.66.203. While certainly not conclusive, it lends credence to the "it's at their end" theory. I'm also going to check the other sites exhibiting the problem. > In any case, the proper fix is probably to complain to slashdot and tell > them to fix their probably broken systems. Unfortunately, without access > to both ends, determining if that is the case for sure isn't easy. I'll send Rob a note. Perhaps it will make a difference; he seems to be a reasonable sort.. -- Dann Lunsford The only thing necessary for the triumph of evil dann@greycat.com is that men of good will do nothing. -- Cicero To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 12 8:49:21 2000 Delivered-To: freebsd-net@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id 7D92E37B80E for ; Mon, 12 Jun 2000 08:49:16 -0700 (PDT) (envelope-from ben@scientia.demon.co.uk) Received: from strontium.scientia.demon.co.uk ([192.168.91.36] ident=exim) by scientia.demon.co.uk with esmtp (Exim 3.12 #1) id 131Vyn-000KKh-00 for net@freebsd.org; Mon, 12 Jun 2000 16:18:21 +0100 Received: (from ben) by strontium.scientia.demon.co.uk (Exim 3.12 #7) id 131Vyn-000POT-00 for net@FreeBSD.org; Mon, 12 Jun 2000 16:18:21 +0100 Date: Mon, 12 Jun 2000 16:18:21 +0100 From: Ben Smithurst To: net@FreeBSD.org Subject: corrupt duplicates with tcpdump + broadcast address Message-ID: <20000612161821.A74118@strontium.scientia.demon.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable (I got no response to this from -questions, perhaps someone here will be able to help.) Can someone give a likely explanation of what could case this: 00:48:19.321320 ff:ff:ff:ff:0:e0 2:0:0:0:ff:ff 7d81 102:=20 749d 0800 4500 0054 a32d 0000 ff01 e0d6 c0a8 5b24 c0a8 5b2f 0800 aeb4 0e3e 0000 c3ea 3a39 4de6 0400 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 00:48:19.321356 0:e0:7d:81:74:9d ff:ff:ff:ff:ff:ff 0800 98: 192.168.91.36 >= 192.168.91.47: icmp: echo request 4500 0054 a32d 0000 ff01 e0d6 c0a8 5b24 c0a8 5b2f 0800 aeb4 0e3e 0000 c3ea 3a39 4de6 0400 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 The second packet is what I actually sent: an echo request to my LAN's broadcast address. Can anyone explain where the junk before the first packet has come from? The packet is just a copy of the real packet but with the four bytes "02 00 00 00" added to the front (tcpdump hides this slightly by printing the source ethernet address first, though the destination address is first in the ethernet header). This bogus packet doesn't appear if I run tcpdump on another host (i.e. the packet isn't on the wire), which is what I'd expected (I've noticed it's normal for broadcast packets to show twice on the source host, but this time it just has some junk in front). This is on a 4.0-stable machine, it also happens on 5.0-current. --=20 Ben Smithurst / ben@scientia.demon.co.uk / PGP: 0x99392F7D --+HP7ph2BbKc20aGI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: B5/SbaggT/O39yVyyTstKVhEnYiso9P7 iQCVAwUBOUT/OysPVtiZOS99AQFAtwP/cJF9KUu9/J84dWFllu+yNDGsPh5Dx1r8 xc//JD1pMRJdpTOVQRzhW9t0MBAgVaqmji82Tss2GoahztDJR2vsm6OhVuoE+fAt rj9tMTO2cKOngqJtxReM0lkDOoFtksrb+aplrvLGuV2TJg3lOHx9606cEXZSacNB bl9dS+Dkz2w= =zwNQ -----END PGP SIGNATURE----- --+HP7ph2BbKc20aGI-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 12 20:15:59 2000 Delivered-To: freebsd-net@freebsd.org Received: from mta02.onebox.com (mta02.onebox.com [216.33.158.209]) by hub.freebsd.org (Postfix) with ESMTP id 094D137B7D6 for ; Mon, 12 Jun 2000 20:15:57 -0700 (PDT) (envelope-from chutima_s@zdnetonebox.com) Received: from onebox.com ([216.33.158.146]) by mta02.onebox.com (InterMail v4.01.01.07 201-229-111-110) with SMTP id <20000613031556.GKL29121.mta02@onebox.com> for ; Mon, 12 Jun 2000 20:15:56 -0700 Received: from [203.107.232.70] by onebox.com with HTTP; Mon, 12 Jun 2000 20:15:56 -0700 Date: Mon, 12 Jun 2000 20:15:56 -0700 Subject: How to: Web service for other website. From: "Chutima S." To: freebsd-net@FreeBSD.ORG Message-Id: <20000613031556.GKL29121.mta02@onebox.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org My company will release web service on internet to other websites. Where can I find technology issue about it? Such as: 1. I know that we can apply DNS to load balancing (round robin). But I like to know can I apply DNS to fault tolorence(if one of our server die all request from customer websites will connect to the rest of our servers)? 2. Our webserver will service several customer websites. How can I use difference URL for each customer website? 3. How can I protect my webserver from other website or browser that is not my customer website? (Someone talk about relay URL.) Thanks, Chutima S. -- Chutima Subsirin chutima_s@zdnetonebox.com - email (202) 777-2641 ext. 6020 - voicemail/fax ___________________________________________________________________ To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, all in one place - sign up today at http://www.zdnetonebox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 12 21: 7:40 2000 Delivered-To: freebsd-net@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id F026A37B923 for ; Mon, 12 Jun 2000 21:07:36 -0700 (PDT) (envelope-from nick@rapidnet.com) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id WAA94990; Mon, 12 Jun 2000 22:07:35 -0600 (MDT) Date: Mon, 12 Jun 2000 22:07:34 -0600 (MDT) From: Nick Rogness To: "Chutima S." Cc: freebsd-net@FreeBSD.ORG Subject: Re: How to: Web service for other website. In-Reply-To: <20000613031556.GKL29121.mta02@onebox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 12 Jun 2000, Chutima S. wrote: > My company will release web service on internet to other websites. > Where can I find technology issue about it? What do you mean by this? Are customers dialing up to your service or what? Are you host web server space? Clarify. > Such as: > 1. I know that we can apply DNS to load balancing (round robin). > But I like to know can I apply DNS to fault tolorence(if one of > our server die all request from customer websites will connect > to the rest of our servers)? What type of remote-access gear are you using? In most types you can setup a primary name server and a secondary (backup) server within your gear. Cisco's allow multiple 'ip name-server' Setup multiple nameservers that are authoritative for your domains. Setup a 'cluster' of machines. > 2. Our webserver will service several customer websites. How > can I use difference URL for each customer website? Apache virtual hosts. Set this up in your web server. > 3. How can I protect my webserver from other website or browser > that is not my customer website? (Someone talk about relay URL.) > This is also setup in your web server. You can setup allowable hosts: Deny from all Allow from .your_domain.com Or you can setup firewall rules: ipfw add 2000 allow tcp from your_ip_range to your_web_server 80 ipfw add 2001 deny tcp from any to your_web_server 80 I don't know exactly what you are asking so I can't be more specific...sorry. Nick Rogness - Speak softly and carry a Gigabit switch. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 12 22:24:56 2000 Delivered-To: freebsd-net@freebsd.org Received: from mta02.onebox.com (mta02.onebox.com [216.33.158.209]) by hub.freebsd.org (Postfix) with ESMTP id 3F40D37B9F2 for ; Mon, 12 Jun 2000 22:24:52 -0700 (PDT) (envelope-from chutima_s@zdnetonebox.com) Received: from onebox.com ([216.33.158.148]) by mta02.onebox.com (InterMail v4.01.01.07 201-229-111-110) with SMTP id <20000613052451.BLU934.mta02@onebox.com>; Mon, 12 Jun 2000 22:24:51 -0700 Received: from [203.107.232.70] by onebox.com with HTTP; Mon, 12 Jun 2000 22:24:51 -0700 Date: Mon, 12 Jun 2000 22:24:51 -0700 Subject: Re: How to: Web service for other website. From: "Chutima S." To: Nick Rogness Cc: freebsd-net@FreeBSD.ORG Message-Id: <20000613052451.BLU934.mta02@onebox.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm sorry for my mail. I really newbie for E-Commerce business. Below is our system. Our webserver will generate output as plain HTML to customer websites. ____________ _______________ | Our | | | | Web Server | | Customer | | with CGI | | Web sites | |____________| |_______________| | | | | ______|_______________________|__________Internet Please forgive me, -- Chutima Subsirin chutima_s@zdnetonebox.com - email ---- Nick Rogness wrote: > On Mon, 12 Jun 2000, Chutima S. wrote: > > > My company will release web service on internet to other websites. > > Where can I find technology issue about it? > > What do you mean by this? Are customers dialing up to your > service or what? Are you host web server space? Clarify. > > > Such as: > > 1. I know that we can apply DNS to load balancing (round robin). > > But I like to know can I apply DNS to fault tolorence(if one of > > our server die all request from customer websites will connect > > to the rest of our servers)? > > What type of remote-access gear are you using? In most types > you can setup a primary name server and a secondary (backup) > server within your gear. Cisco's allow multiple 'ip name-server' > > Setup multiple nameservers that are authoritative for your > domains. > > Setup a 'cluster' of machines. > > > 2. Our webserver will service several customer websites. How > > can I use difference URL for each customer website? > > Apache virtual hosts. Set this up in your web server. > > > > 3. How can I protect my webserver from other website or browser > > that is not my customer website? (Someone talk about relay URL.) > > > > This is also setup in your web server. You can setup allowable > hosts: > > > Deny from all > Allow from .your_domain.com > > > Or you can setup firewall rules: > > ipfw add 2000 allow tcp from your_ip_range to your_web_server > 80 > ipfw add 2001 deny tcp from any to your_web_server 80 > > I don't know exactly what you are asking so I can't be more > specific...sorry. > > > Nick Rogness > - Speak softly and carry a Gigabit switch. > > > ___________________________________________________________________ To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, all in one place - sign up today at http://www.zdnetonebox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 13 0:28:42 2000 Delivered-To: freebsd-net@freebsd.org Received: from bart.esiee.fr (bart.esiee.fr [147.215.1.20]) by hub.freebsd.org (Postfix) with ESMTP id 0FC1937BCA6 for ; Tue, 13 Jun 2000 00:28:40 -0700 (PDT) (envelope-from bonnetf@bart.esiee.fr) Received: (from bonnetf@localhost) by bart.esiee.fr (8.10.1/8.10.1) id e5D7Scx01092 for freebsd-net@freebsd.org; Tue, 13 Jun 2000 09:28:38 +0200 (MEST) From: Frank Bonnet Message-Id: <200006130728.e5D7Scx01092@bart.esiee.fr> Subject: real video proxy for FreeBSD To: freebsd-net@freebsd.org Date: Tue, 13 Jun 2000 9:28:38 MEST X-Mailer: Elm [revision: 212.5] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi I'm search for a real video/audio proxy does it runs with FreeBSD ? is there some free package ? Thanks a lot. -- Frank Bonnet Groupe ESIEE Paris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 13 1:41:43 2000 Delivered-To: freebsd-net@freebsd.org Received: from outbound.mail.ifb.net (outbound.mail.ifb.net [194.105.166.10]) by hub.freebsd.org (Postfix) with ESMTP id 407A137BD39 for ; Tue, 13 Jun 2000 01:41:38 -0700 (PDT) (envelope-from IT.Department@grampian.police.uk) Received: from rudolph ([194.105.164.13]) by outbound.mail.ifb.net (8.9.3/8.9.3) with SMTP id JAA04897 for ; Tue, 13 Jun 2000 09:36:09 +0100 Message-ID: <000801bfd514$5625e710$0da469c2@rudolph> From: "IT Department" To: Subject: Deleteing no permanent routes from my routing tables. Date: Tue, 13 Jun 2000 09:49:50 +0100 Organization: Grampian Police MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01BFD51C.B7BE0EF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BFD51C.B7BE0EF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sir, I hope you can help, but I have a number of routes defined when I = do a netstat -r command (aix 4.3) there are a number that have the flag UGHDM which I understand = means that they are=20 routes that are only temporary i.e dynamic, firstly is this correct and = secondly how can I remove these entries without having to reboot? I can use the route -f command, but I = think that this will clear ALL routes that I have defined.This I do not want to do..... Any help would be gratefully received. Rob Mcwilliam. ------=_NextPart_000_0005_01BFD51C.B7BE0EF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sir, I hope you can help, but I have a = number of=20 routes defined when I do a netstat -r command
(aix 4.3) there are a number that have = the flag=20 UGHDM which I understand means that they are
routes that are only temporary i.e = dynamic, firstly=20 is this correct and secondly how can I remove these
entries without having to reboot? I can = use the=20 route -f command, but I think that this will clear ALL
routes that I have defined.This I do = not want to=20 do.....
 
Any help would be gratefully = received.
 
Rob = Mcwilliam.
------=_NextPart_000_0005_01BFD51C.B7BE0EF0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 13 11:23:23 2000 Delivered-To: freebsd-net@freebsd.org Received: from larryboy.graphics.cornell.edu (larryboy.graphics.cornell.edu [128.84.247.48]) by hub.freebsd.org (Postfix) with ESMTP id 7493C37B8F4 for ; Tue, 13 Jun 2000 11:23:21 -0700 (PDT) (envelope-from mkc@larryboy.graphics.cornell.edu) Received: from larryboy.graphics.cornell.edu (mkc@localhost) by larryboy.graphics.cornell.edu (8.9.3/8.9.3) with ESMTP id OAA78780; Tue, 13 Jun 2000 14:18:04 -0400 (EDT) (envelope-from mkc@larryboy.graphics.cornell.edu) Message-Id: <200006131818.OAA78780@larryboy.graphics.cornell.edu> To: "CyberSniper" Cc: freebsd-net@FreeBSD.ORG Subject: Re: Off topic, sorta: home RJ-45 wiring In-Reply-To: Message from "CyberSniper" of "Sun, 11 Jun 2000 00:01:17 EDT." <002901bfd359$f0d53d40$02000a0a@wrath01> Date: Tue, 13 Jun 2000 14:18:04 -0400 From: Mitch Collinsworth Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >you'll also need to acquire an outlet/switch box for each wallplate, a 3/8" You really do not need a outlet boxes for data outlets. Milestek (www.milestek.com) sells single and double wall-plate mounting brackets that clamp to a hole in the wall. See their part number 60-01001 and 60-01002. You can mount any standard size wall plate to these. -Mitch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 13 14:23:23 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.alltel.net (mail.alltel.net [166.102.165.30]) by hub.freebsd.org (Postfix) with ESMTP id 0F93637B72C for ; Tue, 13 Jun 2000 14:23:15 -0700 (PDT) (envelope-from jbstrt@alltel.net) Received: from alltel.net (r-251.86.alltel.net [166.102.251.86]) by mail.alltel.net (8.9.3/8.9.3/ALLTEL Internet) with ESMTP id QAA04993 for ; Tue, 13 Jun 2000 16:23:12 -0500 (CDT) Message-ID: <3946A820.84701195@alltel.net> Date: Tue, 13 Jun 2000 17:31:12 -0400 From: Robert Fulford X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG Subject: ident,irc, & win2k question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Howdy all.... I previously posted this question in Freebsd-newbies, and received no answer...please excuse the flooding... :( I have an unusual setup here at home, and the fact that I am relatively new to *nix & FreeBSD, which doesn't help matters much.... :(....Here is what I have to work with.. Netgear RT-338 ISDN router that does NAT exceptionally well and gets a dynamic IP from my ISP....the internal IP of the router is 192.168.0.1....I set the DHCP pool on the Netgear to a pool size of 2 & a starting IP of 192.168.0.2. This works well with the 2 nic's in the fbsd 4.0 release box, with dc0 being 192.168.0.2 & hooked to the router. dc1 is 192.168.150.150 & is hooked to a hub, where 2 Win2k boxes also connect, <192.168.150.154 & 192.168.150.156>. I run mIRC version 5.61 on the 2 Win2k boxes, but usually only use one Win2k box when I am on mIRC. I don't run gated or routed or any daemons, I just did some persistant routes on the 2 Win2k boxes & all I have to do after boot-time on the fbsd box is ping the .154 & the .156 and then do a route add -net 0.0.0.0 192.168.0.1...(seems there is a bug with 4.0 not accepting "sticky" routes, or I have my syntax wrong in rc.conf, even with .1 being the default_router).... My goal is to get ident or socks5 or anything working in a setup like this so I can use mIRC on a Win2k box. I get "identd not installed" or other similar errors on the Efnet servers that I would like to use....these servers do not give me the error when I use the modem on the Win2k to connect to the ISP & use mIRC...the fbsd box & the router are not in the loop when using the modem, so it's mainly ident that I need to get working..... Here is what some things look like on my fbsd box..... I have installed & compiled pidentd-2.8.5.tar.gz I have installed & compiled socks5-v1.0r10.tar.gz I did not use any arguments when i compiled them.... i just went to /usr/ports/ and did a "make depend", then a "make", then "make install".....it fetched the files it needed and put them in /usr/ports/distfiles/. I have a file in /etc/ called socks5.conf which contains.... set SOCKS5_V4SUPPORT permit - - 192. - - - homers I also have a /usr/local/etc/socks5.conf. This file is a copy of the one in /etc/. The man page mentioned both locations as places it would look, i'll remove the un-needed one later. i have every option in /etc/inetd.conf remarked out with a # i have not made any scripts for identd at all. i tried starting it as suggested, /usr/local/sbin/identd -S /usr/tmp/socks5.ident, but it gave me an error....i read the man page on identd and it said this.... The -f option causes identd to use the named config file (instead of the default /etc/identd.conf ?). Currently not used: ignored, no config files are used. Also, i didn't see a -S option in "man identd"...(i had the /usr/tmp/ socks5.ident file as suggested....it was exactly like this...) set SOCKS5_V4SUPPORT permit - - 192. - - - homers i have tried /usr/local/sbin/identd and then i did a /usr/local/bin/socks5 and tried to join an irc server... no luck at all :( Any help would be greatly appreciated, Jeb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 13 18:16: 5 2000 Delivered-To: freebsd-net@freebsd.org Received: from alpha.shianet.org (alpha.shianet.org [216.40.132.245]) by hub.freebsd.org (Postfix) with ESMTP id 9AC6137BD17 for ; Tue, 13 Jun 2000 18:16:01 -0700 (PDT) (envelope-from wrath@shianet.org) Received: from wrath01 (port37.owosso18.tir.com [216.40.135.176]) by alpha.shianet.org (8.9.1/8.9.1) with SMTP id VAA18929 for ; Tue, 13 Jun 2000 21:14:49 -0400 (EDT) Message-ID: <002501bfd59e$1237d060$02000a0a@wrath01> From: "CyberSniper" To: References: <200006131818.OAA78780@larryboy.graphics.cornell.edu> Subject: Re: Off topic, sorta: home RJ-45 wiring Date: Tue, 13 Jun 2000 21:15:24 -0400 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.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I hate to be a pain in the butt, but you can buy a single plastic box for 60 cents at your local hardware store, and that's for the expensive type that come with the nails and locator tabs. Seventy-five cents plus shipping and handling seems a little pricey to me, but I suppose it has a purpose and is probably simpler than putting boxes in. -Brian ----- Original Message ----- From: "Mitch Collinsworth" To: "CyberSniper" Cc: Sent: Tuesday, June 13, 2000 2:18 PM Subject: Re: Off topic, sorta: home RJ-45 wiring > > > >you'll also need to acquire an outlet/switch box for each wallplate, a 3/8" > > You really do not need a outlet boxes for data outlets. Milestek > (www.milestek.com) sells single and double wall-plate mounting brackets > that clamp to a hole in the wall. See their part number 60-01001 > and 60-01002. You can mount any standard size wall plate to these. > > -Mitch > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 13 19:13:32 2000 Delivered-To: freebsd-net@freebsd.org Received: from larryboy.graphics.cornell.edu (larryboy.graphics.cornell.edu [128.84.247.48]) by hub.freebsd.org (Postfix) with ESMTP id EEA1537B59B for ; Tue, 13 Jun 2000 19:13:30 -0700 (PDT) (envelope-from mkc@larryboy.graphics.cornell.edu) Received: from larryboy.graphics.cornell.edu (mkc@localhost) by larryboy.graphics.cornell.edu (8.9.3/8.9.3) with ESMTP id WAA81235; Tue, 13 Jun 2000 22:11:31 -0400 (EDT) (envelope-from mkc@larryboy.graphics.cornell.edu) Message-Id: <200006140211.WAA81235@larryboy.graphics.cornell.edu> To: "CyberSniper" Cc: freebsd-net@FreeBSD.ORG Subject: Re: Off topic, sorta: home RJ-45 wiring In-Reply-To: Message from "CyberSniper" of "Tue, 13 Jun 2000 21:15:24 EDT." <002501bfd59e$1237d060$02000a0a@wrath01> Date: Tue, 13 Jun 2000 22:11:31 -0400 From: Mitch Collinsworth Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I hate to be a pain in the butt, but you can buy a single plastic box for 60 >cents at your local hardware store, and that's for the expensive type that >come with the nails and locator tabs. > >Seventy-five cents plus shipping and handling seems a little pricey to me, >but I suppose it has a purpose and is probably simpler than putting boxes >in. Yes, a whole lot simpler when you consider it can be installed after the walls are finished. The plastic box you describe has to be installed before the sheetrock. Of course there is a different type of plastic box you didn't mention that installs in the same fashion as the Milestek wall plate mounting bracket, but why bother with a box when it isn't necessary? -Mitch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 13 21:54:33 2000 Delivered-To: freebsd-net@freebsd.org Received: from obie.softweyr.com (obie.softweyr.com [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id D189C37BD2C for ; Tue, 13 Jun 2000 21:52:44 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (Foolstrustident!@homer.softweyr.com [204.68.178.39]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id WAA20084; Tue, 13 Jun 2000 22:48:18 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <39470EBC.459ED684@softweyr.com> Date: Tue, 13 Jun 2000 22:49:00 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: CyberSniper Cc: freebsd-net@FreeBSD.ORG Subject: Re: Off topic, sorta: home RJ-45 wiring References: <200006131818.OAA78780@larryboy.graphics.cornell.edu> <002501bfd59e$1237d060$02000a0a@wrath01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org CyberSniper wrote: > > I hate to be a pain in the butt, but you can buy a single plastic box for 60 > cents at your local hardware store, and that's for the expensive type that > come with the nails and locator tabs. > > Seventy-five cents plus shipping and handling seems a little pricey to me, > but I suppose it has a purpose and is probably simpler than putting boxes > in. $0.19 for the cheap blue ones here. Modular connectors are a lot less, too. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 14 5: 0:46 2000 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 032DE37C140; Wed, 14 Jun 2000 05:00:19 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.9.3/1.13) id OAA83271; Wed, 14 Jun 2000 14:59:57 +0300 (EEST) Date: Wed, 14 Jun 2000 14:59:57 +0300 From: Ruslan Ermilov To: Erik Salander Cc: net@FreeBSD.org, Archie Cobbs , Julian Elischer , Eivind Eklund , Kris Kennaway , Warner Losh , Brian Somers , Charles Mott Subject: Re: libalias changes for PPTP, RTSP, FTP(passive) Message-ID: <20000614145957.A83146@sunbay.com> Mail-Followup-To: Erik Salander , net@FreeBSD.org, Archie Cobbs , Julian Elischer , Eivind Eklund , Kris Kennaway , Warner Losh , Brian Somers , Charles Mott References: <392C655B.5966AE30@whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <392C655B.5966AE30@whistle.com>; from erik@whistle.com on Wed, May 24, 2000 at 04:27:23PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, May 24, 2000 at 04:27:23PM -0700, Erik Salander wrote: > > Hi, > > I've got some changes for libalias that are ready to be reviewed. The > general features are: > > - add support to alias RTSP and RTP (see new module alias_rtsp.c) > - add support to alias PPTP and GRE (see new module alias_pptp.c and > all "LINK_GRE" references) > What I do not understand is how PPTP is supposed to work if we do not intercept outgoing GRE packets. I was told by Archie (and then read about that in RFC) that multiple clients to the same server can use the same Call ID. I understand what is going on in alias_pptp.c -- a GRE link is created after successful PPTP handshake, and then, for incoming packets, we look for the corresponding GRE link in GreAliasIn() and simply replace Call ID there appropriately (PPTP's GRE does not use checksum, right?), but we should do the same thing in GreAliasOut(), which is missing. Am I overlooked something? > - adding support for passive mode FTP, aliasing the 227 replies (see > alias_ftp.c) > The EPSV command 229 reply (RFC2428) should be aliased and checked as well. Recent versions of FreeBSD use EPSV by default: : Connected to localhost. : 220 perl.sunbay.crimea.ua FTP server (Version 6.00LS) ready. : Name (localhost:ru): : ---> USER ru : 331 Password required for ru. : Password: : ---> PASS XXXX : 230 User ru logged in. : ---> SYST : 215 UNIX Type: L8 Version: BSD-199506 : Remote system type is UNIX. : Using binary mode to transfer files. : ftp> dir foo : ---> EPSV : 229 Entering Extended Passive Mode (|||49169|) : ---> LIST foo : 150 Opening ASCII mode data connection for '/bin/ls'. : ftpd: foo: No such file or directory : 226 Transfer complete. : ftp> quit : ---> QUIT : 221 Goodbye. > - a new utility function, PacketUnaliasOut (see alias.c) > I have left it out as well as QueryUdpTcp*(). > Note, the FTP aliasing now ensures that: > > 1. the segment preceding a PORT/227 segment terminates with a \r\n. > 2. the IP address in the PORT/227 matches the source IP address of > the packet. > 3. the port number in the PORT command or 277 reply is greater than > or equal to 1024 Additional minor changes I have made: - Moved data structures declarations local to alias_db.c back from alias_local.h to alias_db.c; - New functions {Set|Get}LastLineCrlfTermed() for use instead of explicitly manipulating link flags inside alias_ftp.c; And I have put the new version of patch: http://people.FreeBSD.org/~ru/libalias.patch.2 I still have to have my questions answered in order to commit PPTP part of this patch. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 14 6:45: 6 2000 Delivered-To: freebsd-net@freebsd.org Received: from dm.deskmedia.com (dm.deskmedia.com [199.199.147.32]) by hub.freebsd.org (Postfix) with ESMTP id 4670B37BB31 for ; Wed, 14 Jun 2000 06:45:03 -0700 (PDT) (envelope-from brian@pitel.net) Received: from pitel.net (pineisland-135.deskmedia.com [206.53.194.135]) by dm.deskmedia.com (8.9.3/8.8.7) with ESMTP id IAA19303 for ; Wed, 14 Jun 2000 08:45:01 -0500 Message-ID: <39478C4D.34DF02D8@pitel.net> Date: Wed, 14 Jun 2000 08:44:45 -0500 From: Brian Olson X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: help! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm trying to configure a FreeBSD 3.4 machine to run Samba and NATD I have installed Samba and it works great. However, when I install the second NIC for NATD, the SMB daemon refuses to run. My understanding is that the "INTERFACES" parameter in smb.conf needs to be set to the ip of the internal network interface and also to 127.0.0.1 and the "BIND INTERFACE ONLY" parameter set to "YES". I have done these things and yet the SMB daemon refuses to run. Any help would be appreciated. Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 14 6:59:51 2000 Delivered-To: freebsd-net@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id 30D5237C1D7 for ; Wed, 14 Jun 2000 06:59:46 -0700 (PDT) (envelope-from nick@rapidnet.com) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id HAA83620; Wed, 14 Jun 2000 07:59:28 -0600 (MDT) Date: Wed, 14 Jun 2000 07:59:28 -0600 (MDT) From: Nick Rogness To: Brian Olson Cc: freebsd-net@freebsd.org Subject: Re: help! In-Reply-To: <39478C4D.34DF02D8@pitel.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 14 Jun 2000, Brian Olson wrote: > I'm trying to configure a FreeBSD 3.4 machine to run Samba and NATD > I have installed Samba and it works great. However, when I install the > second NIC for NATD, the SMB daemon refuses to run. My understanding > is that the "INTERFACES" parameter in smb.conf needs to be set to the > ip of the internal network interface and also to 127.0.0.1 and the "BIND > INTERFACE ONLY" parameter set to "YES". I have done these things and > yet the SMB daemon refuses to run. Any help would be appreciated. What does the samba log file say when you start it up? Nick Rogness - Speak softly and carry a Gigabit switch. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 14 11:20:11 2000 Delivered-To: freebsd-net@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 97CCD37B7D9; Wed, 14 Jun 2000 11:20:06 -0700 (PDT) (envelope-from erik@whistle.com) Received: from whistle.com (erik.whistle.com [207.76.205.71]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id LAA67741; Wed, 14 Jun 2000 11:18:55 -0700 (PDT) Message-ID: <3947CC8F.8D755E78@whistle.com> Date: Wed, 14 Jun 2000 11:18:55 -0700 From: Erik Salander X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Ruslan Ermilov Cc: net@FreeBSD.org, Archie Cobbs , Julian Elischer , Eivind Eklund , Kris Kennaway , Warner Losh , Brian Somers , Charles Mott Subject: Re: libalias changes for PPTP, RTSP, FTP(passive) References: <392C655B.5966AE30@whistle.com> <20000614145957.A83146@sunbay.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ruslan Ermilov wrote: > On Wed, May 24, 2000 at 04:27:23PM -0700, Erik Salander wrote: > > > > Hi, > > > > I've got some changes for libalias that are ready to be reviewed. The > > general features are: > > > > - add support to alias RTSP and RTP (see new module alias_rtsp.c) > > - add support to alias PPTP and GRE (see new module alias_pptp.c and > > all "LINK_GRE" references) > > > What I do not understand is how PPTP is supposed to work if we do not > intercept outgoing GRE packets. I was told by Archie (and then read > about that in RFC) that multiple clients to the same server can use > the same Call ID. I understand what is going on in alias_pptp.c -- > a GRE link is created after successful PPTP handshake, and then, for > incoming packets, we look for the corresponding GRE link in GreAliasIn() > and simply replace Call ID there appropriately (PPTP's GRE does not use > checksum, right?), but we should do the same thing in GreAliasOut(), > which is missing. Am I overlooked something? I dredged up an email in which Charles and Archie discussed this in detail, sent it to you separately FYI. The net of their discussion was that PPTP aliasing is almost identical to FTP aliasing - except we use the Call ID instead of the port number. FTP clients (behind the same NAT service) could have the same port number in their PORT command. So similarly, we'll have to alter the Call ID in the PPTP control stream. About outgoing GRE translation... A session is defined by a triple (PAC, PNS, Call ID). But it's not (necessarily) the same triple at the PAC as it is at the PNS. They'll each have their own individually obtained Call ID. Theoretically, could be the same value. So when we have an outgoing GRE, it's the destination's Call ID. I refer to it as the "other guy's" Call ID, not ours to translate. PPTP's GRE does not calculate a checksum. > > - adding support for passive mode FTP, aliasing the 227 replies (see > > alias_ftp.c) > > > The EPSV command 229 reply (RFC2428) should be aliased and checked as well. > Recent versions of FreeBSD use EPSV by default: > > : Connected to localhost. > : 220 perl.sunbay.crimea.ua FTP server (Version 6.00LS) ready. > : Name (localhost:ru): > : ---> USER ru > : 331 Password required for ru. > : Password: > : ---> PASS XXXX > : 230 User ru logged in. > : ---> SYST > : 215 UNIX Type: L8 Version: BSD-199506 > : Remote system type is UNIX. > : Using binary mode to transfer files. > : ftp> dir foo > : ---> EPSV > : 229 Entering Extended Passive Mode (|||49169|) > : ---> LIST foo > : 150 Opening ASCII mode data connection for '/bin/ls'. > : ftpd: foo: No such file or directory > : 226 Transfer complete. > : ftp> quit > : ---> QUIT > : 221 Goodbye. Will begin to look into this. We can discuss more. > > - a new utility function, PacketUnaliasOut (see alias.c) > > > I have left it out as well as QueryUdpTcp*(). Keep in mind, I had libalias.3 mods for PacketUnaliasOut. As you probably know, QueryUdpTcp* was necessary to "lookahead" for available alias values without actually allocating them. I used this to acquire contiguous port numbers (so far, just a pair) for RTSP. > > Note, the FTP aliasing now ensures that: > > > > 1. the segment preceding a PORT/227 segment terminates with a \r\n. > > 2. the IP address in the PORT/227 matches the source IP address of > > the packet. > > 3. the port number in the PORT command or 277 reply is greater than > > or equal to 1024 > > Additional minor changes I have made: > > - Moved data structures declarations local to alias_db.c back from > alias_local.h to alias_db.c; > - New functions {Set|Get}LastLineCrlfTermed() for use instead of > explicitly manipulating link flags inside alias_ftp.c; That sounds like a better idea. > And I have put the new version of patch: > > http://people.FreeBSD.org/~ru/libalias.patch.2 > > > I still have to have my questions answered in order to commit PPTP > part of this patch. > I understand. Thanks again for your review. Erik To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 14 14:16: 6 2000 Delivered-To: freebsd-net@freebsd.org Received: from dune.clickarray.com (mail.puretek.com [216.174.91.46]) by hub.freebsd.org (Postfix) with ESMTP id 011FF37C29C for ; Wed, 14 Jun 2000 14:16:03 -0700 (PDT) (envelope-from sshah@dune.clickarray.com) Received: (from sshah@localhost) by dune.clickarray.com (8.9.3/8.9.3) id OAA01950 for freebsd-net@freebsd.org; Wed, 14 Jun 2000 14:16:02 -0700 Date: Wed, 14 Jun 2000 14:16:02 -0700 From: Steve Shah To: freebsd-net@freebsd.org Subject: persistant ssh connections Message-ID: <20000614141602.A1932@clickarray.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Gang, I want to setup ssh port forwarding in such a way that they can be started without user intervention. I already have the keys setup in a way that allows me to do things like: [user@host ~]$ ssh -L 5555:localhost:5555 remote.host.com without having to enter a password. But now I have to maintain activity on the link so that the forwarding doesn't get dropped. =( I tried various combinations of -f -n and -S without success. I'm sure it is something straight forward. Any enlightment would be much appreciated. Thanks, -Steve -- ___________________________________________________________________________ Steve Shah (sshah@clickarray.com) | Developer/Systems Administrator/Author http://www.clickarray.com | Voice: 408.772.8202 (e-mail preferred) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Beating code into submission, one OS at a time... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 14 14:46:41 2000 Delivered-To: freebsd-net@freebsd.org Received: from databus.databus.com (databus.databus.com [198.186.154.34]) by hub.freebsd.org (Postfix) with SMTP id 5F1F837B731 for ; Wed, 14 Jun 2000 14:46:34 -0700 (PDT) (envelope-from barney@databus.databus.com) From: Barney Wolff To: freebsd-net@freebsd.org Date: Wed, 14 Jun 2000 17:46 EDT Subject: Re: persistant ssh connections Content-Length: 862 Content-Type: text/plain Message-ID: <3947fd330.2183@databus.databus.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Perhaps the shell at the far end has an idle timer. For ksh, set TMOUT=0. I need hardly tell you how dangerous unattended ssh, with or without forwarding, is. Sure wouldn't do it on my network. Barney Wolff > Date: Wed, 14 Jun 2000 14:16:02 -0700 > From: Steve Shah > > I want to setup ssh port forwarding in such a way that they > can be started without user intervention. I already have the > keys setup in a way that allows me to do things like: > > [user@host ~]$ ssh -L 5555:localhost:5555 remote.host.com > > without having to enter a password. But now I have to maintain activity > on the link so that the forwarding doesn't get dropped. =( I tried > various combinations of -f -n and -S without success. > > I'm sure it is something straight forward. Any enlightment would be > much appreciated. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 14 15: 5: 1 2000 Delivered-To: freebsd-net@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id DDAC337B52A for ; Wed, 14 Jun 2000 15:04:52 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.3/frmug-2.7/nospam) with UUCP id AAA02533 for freebsd-net@freebsd.org; Thu, 15 Jun 2000 00:04:48 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 0334E87AE; Thu, 15 Jun 2000 00:01:37 +0200 (CEST) Date: Thu, 15 Jun 2000 00:01:37 +0200 From: Ollivier Robert To: freebsd-net@freebsd.org Subject: Re: persistant ssh connections Message-ID: <20000615000137.A20485@keltia.freenix.fr> Mail-Followup-To: freebsd-net@freebsd.org References: <20000614141602.A1932@clickarray.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000614141602.A1932@clickarray.com>; from sshah@clickarray.com on Wed, Jun 14, 2000 at 02:16:02PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT/ELF AMD-K6/200 & 2x PPro/200 SMP Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Steve Shah: > [user@host ~]$ ssh -L 5555:localhost:5555 remote.host.com Add "sleep 5000" after that and "-f -n" . That way, you'll have time to open forwarded connections and after the sleep wakes up, ssh will wait till all connections are closed to exit. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 14 21:28:47 2000 Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id EDD9237B5D2 for ; Wed, 14 Jun 2000 21:28:44 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.3/8.9.1) with ESMTP id AAA84349; Thu, 15 Jun 2000 00:23:42 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200006150423.AAA84349@whizzo.transsys.com> To: Mitch Collinsworth Cc: "CyberSniper" , freebsd-net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: Off topic, sorta: home RJ-45 wiring References: <200006140211.WAA81235@larryboy.graphics.cornell.edu> In-reply-to: Your message of "Tue, 13 Jun 2000 22:11:31 EDT." <200006140211.WAA81235@larryboy.graphics.cornell.edu> Date: Thu, 15 Jun 2000 00:23:42 -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The reason you don't want a box, and would rather use the brackets has nothing to do with cost. Using the brackets gives you much mjore volume to store the cable in the wall, rather than trying to shove it all inside an electrical box. This isn't a huge deal with CAT5 cable, but if you've got some RG6 coax, it's a bit, big win. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 15 7:53:34 2000 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id A144337BB84; Thu, 15 Jun 2000 07:52:14 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.9.3/1.13) id RAA16413; Thu, 15 Jun 2000 17:51:15 +0300 (EEST) Date: Thu, 15 Jun 2000 17:51:15 +0300 From: Ruslan Ermilov To: Erik Salander Cc: net@FreeBSD.org, Archie Cobbs , Julian Elischer , Brian Somers , Charles Mott Subject: Re: libalias changes for PPTP, RTSP, FTP(passive) Message-ID: <20000615175115.A13791@sunbay.com> Mail-Followup-To: Erik Salander , net@FreeBSD.org, Archie Cobbs , Julian Elischer , Brian Somers , Charles Mott References: <392C655B.5966AE30@whistle.com> <20000614145957.A83146@sunbay.com> <3947CC8F.8D755E78@whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3947CC8F.8D755E78@whistle.com>; from erik@whistle.com on Wed, Jun 14, 2000 at 11:18:55AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Jun 14, 2000 at 11:18:55AM -0700, Erik Salander wrote: > Ruslan Ermilov wrote: > [...] > About outgoing GRE translation... A session is defined by a triple (PAC, PNS, > Call ID). But it's not (necessarily) the same triple at the PAC as it is at > the PNS. They'll each have their own individually obtained Call ID. > Theoretically, could be the same value. So when we have an outgoing GRE, it's > the destination's Call ID. I refer to it as the "other guy's" Call ID, not > ours to translate. > Okay, I understand. I have modified PPTP part of the patch and want you to review and test it. After that I could commit it. Unfortunately, I do not have enough test environment here, so additional testers are highly welcome. What has been modified (in short): - All PPTP related stuff including `struct grehdr' has been moved into alias_pptp.c. - LINK_GRE was renamed to LINK_PPTP to allow IPPROTO_GRE (but non-PPTP) links to co-exist, see below. - GreAliasIn() now uses two PPTP interface functions: PptpGetCallID() and PptpSetCallID() instead of explicitly manipulating GRE packets. PptpGetCallID() ensures that the passed packet is actually PPTP GRE packet by checking GRE header version and presence of Key field. Otherwise, GreAliasIn() defaults to ProtoAliasIn(). This should allow for PPTP GRE to co-exist with other GRE protocols. - AliasHandlePptp*() now use FindPptp*() instead of FindUdpTcp*(). The problem was that links were added with zero dst_port, and that caused them to be always LINK_PARTIALLY_SPECIFIED. Now PPTP links use NO_DEST_PORT as dst_port. As a side effect, there is no more need to check for link to be of type LINK_TCP or LINK_UDP in GetNewPort(), but I decided to let it be :-) - I also added checks for return values from FindPptp*() from within AliasHandlePptp*(). Before this, incoming PPTP (port 1723) packet could cause a NULL pointer dereference problem if running with PKT_ALIAS_DENY_INCOMING. I have put the patch against the -current libalias sources here: http://people.FreeBSD.org/~ru/libalias.pptp_patch.1.gz Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 15 7:55:15 2000 Delivered-To: freebsd-net@freebsd.org Received: from sabre.velocet.net (sabre.velocet.net [198.96.118.66]) by hub.freebsd.org (Postfix) with ESMTP id 9A68137B542; Thu, 15 Jun 2000 07:55:07 -0700 (PDT) (envelope-from dgilbert@office.tor.velocet.net) Received: from office.tor.velocet.net (trooper.velocet.net [216.126.82.226]) by sabre.velocet.net (Postfix) with ESMTP id 245AA137F6C; Thu, 15 Jun 2000 10:55:01 -0400 (EDT) Received: (from dgilbert@localhost) by office.tor.velocet.net (8.9.3/8.9.3) id KAA91901; Thu, 15 Jun 2000 10:54:57 -0400 (EDT) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14664.60992.300592.147710@trooper.velocet.net> Date: Thu, 15 Jun 2000 10:54:56 -0400 (EDT) To: FreeBSD-wizards@freebsd.org, freebsd-net@freebsd.org Subject: "frag-anyways" knob. X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As offensive as this is, there are enough badly firewalled sites out there that send 1500 byte packets with the DF (don't frag) bit set and firewall out returning must-frag packets that I could really use a patch that broke RFC and fragmented the packets anyways. Due to the stupidity of our local telco (among other problems) we're faced with a link that has a lower-than-1500 MTU and the only current way for our users to hit this community of broken sites is to use our proxy. For some, this is an inadequate solution. Furthermore, there exist online games that count on a 1500 byte MTU _and_ still set the DF bit. I could really use a sysctl knob that would fragment the packet regardless of the DF bit. It might also be prudent to clear the DF bit in generated packets :). Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | 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 Jun 15 11:54: 8 2000 Delivered-To: freebsd-net@freebsd.org Received: from mercury.spvi.com (h194.spvi.com [208.150.70.194]) by hub.freebsd.org (Postfix) with ESMTP id D393A37B7C4 for ; Thu, 15 Jun 2000 11:54:01 -0700 (PDT) (envelope-from steve@mercury.spvi.com) Received: (from steve@localhost) by mercury.spvi.com (8.9.3/8.9.3) id NAA01063; Thu, 15 Jun 2000 13:51:07 -0500 (EST) (envelope-from steve) Date: Thu, 15 Jun 2000 13:51:07 -0500 (EST) Message-Id: <200006151851.NAA01063@mercury.spvi.com> From: Steve Spicklemire To: freebsd-net@freebsd.org Subject: mpd and pptp and M$ MPPE Reply-To: steve@spvi.com Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is wierd! I got this to work once.. and now it's not. Just did a cvsup of 4.0s. I rebuilt the kernel with NETGRAPH and I can't seem to get it to work now.... I'm getting flooded with lots of unexpected protocol COMPD messages in mpd.log. Any idea what that's about? thanks, -steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 15 12:28:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from mercury.spvi.com (h194.spvi.com [208.150.70.194]) by hub.freebsd.org (Postfix) with ESMTP id 101B337C3E4 for ; Thu, 15 Jun 2000 12:28:12 -0700 (PDT) (envelope-from steve@mercury.spvi.com) Received: (from steve@localhost) by mercury.spvi.com (8.9.3/8.9.3) id OAA01318; Thu, 15 Jun 2000 14:25:16 -0500 (EST) (envelope-from steve) Date: Thu, 15 Jun 2000 14:25:16 -0500 (EST) Message-Id: <200006151925.OAA01318@mercury.spvi.com> From: Steve Spicklemire To: freebsd-net@freebsd.org Cc: steve@spvi.com Subject: Problems with mpd netgraph... Reply-To: steve@spvi.com Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Help! I'm trying to work out a problem I'm somehow having with mpd-negraph and M$ pptp/VPN. I get this in mpd.log: pptp] CCP: rec'd Configure Request #2 link 0 (Req-Sent) [pptp] CCP: SendConfigAck #2 [pptp] CCP: state change Req-Sent --> Ack-Sent [pptp] CCP: rec'd Configure Ack #2 link 0 (Ack-Sent) [pptp] CCP: state change Ack-Sent --> Opened [pptp] CCP: LayerUp [pptp] can't create mppc node: Device not configured [pptp] CCP: parameter negotiation failed [pptp] CCP: Close event [pptp] CCP: state change Opened --> Closing [pptp] CCP: SendTerminateReq #3 [pptp] CCP: LayerDown [pptp] CCP: state change Closing --> Closed [pptp] CCP: LayerFinish [pptp] IPCP: rec'd Configure Request #3 link 0 (Ack-Rcvd) COMPPROTO VJCOMP, 16 comp. channels, allow comp-cid IPADDR 10.0.0.2 10.0.0.2 is OK PRIDNS 10.0.0.1 [pptp] IPCP: SendConfigAck #3 COMPPROTO VJCOMP, 16 comp. channels, allow comp-cid IPADDR 10.0.0.2 PRIDNS 10.0.0.1 [pptp] IPCP: state change Ack-Rcvd --> Opened [pptp] IPCP: LayerUp 10.0.0.1 -> 10.0.0.2 [pptp] IFACE: Up event [pptp] exec: /sbin/ifconfig ng0 10.0.0.1 10.0.0.2 netmask 0xffffffff -link0 [pptp] exec: /usr/sbin/arp -s 10.0.0.2 0:c0:ca:12:19:a5 pub [pptp] CCP: rec'd Terminate Ack #3 link 0 (Closed) [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 ----------------------------------------------------------------------- I get this from tcpdump.. is there any better way to figure this out? ---------------------------------------------------------------------- 983 packets received by filter 0 packets dropped by kernel mercury# tcpdump host h202 tcpdump: listening on rl0 14:13:26.091197 h202.spvi.com > h194.spvi.com: gre-proto-0x880B (gre encap) 14:13:26.106234 h194.spvi.com > h202.spvi.com: [|gre] (gre encap) 14:13:27.809186 h202.spvi.com > h194.spvi.com: gre-proto-0x880B (gre encap) 14:13:27.826258 h194.spvi.com > h202.spvi.com: [|gre] (gre encap) 14:13:29.350083 h202.spvi.com > h194.spvi.com: gre-proto-0x880B (gre encap) 14:13:29.366280 h194.spvi.com > h202.spvi.com: [|gre] (gre encap) 14:13:30.894248 h202.spvi.com > h194.spvi.com: gre-proto-0x880B (gre encap) 14:13:30.906299 h194.spvi.com > h202.spvi.com: [|gre] (gre encap) 14:13:31.696385 h194.spvi.com.pptp > h202.spvi.com.iad3: P 2432991799:2432991815(16) ack 576815 win 17520 (DF) 14:13:31.699530 h202.spvi.com.iad3 > h194.spvi.com.pptp: P 1:21(20) ack 16 win 8524 (DF) 14:13:31.796307 h194.spvi.com.pptp > h202.spvi.com.iad3: . ack 21 win 17520 (DF) 14:13:43.886730 h194.spvi.com > h202.spvi.com: gre-proto-0x880B (gre encap) 14:13:43.903537 h202.spvi.com > h194.spvi.com: gre-proto-0x880B (gre encap) 14:13:43.906485 h194.spvi.com > h202.spvi.com: [|gre] (gre encap) 14:14:03.907059 h194.spvi.com > h202.spvi.com: gre-proto-0x880B (gre encap) 14:14:03.923258 h202.spvi.com > h194.spvi.com: gre-proto-0x880B (gre encap) 14:14:03.926788 h194.spvi.com > h202.spvi.com: [|gre] (gre encap) ^C 161 packets received by filter 0 packets dropped by kernel thanks, -steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 15 12:55: 2 2000 Delivered-To: freebsd-net@freebsd.org Received: from garm.bart.nl (garm.bart.nl [194.158.170.13]) by hub.freebsd.org (Postfix) with ESMTP id 12A1A37BDDA; Thu, 15 Jun 2000 12:54:55 -0700 (PDT) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org (lucifer.is.an.elder.of.the.ninth-circle.org [195.38.216.226]) by garm.bart.nl (8.10.1/8.10.1) with ESMTP id e5FJsjW75977; Thu, 15 Jun 2000 21:54:46 +0200 (CEST) Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id VAA17539; Thu, 15 Jun 2000 21:54:47 +0200 (CEST) (envelope-from asmodai) Date: Thu, 15 Jun 2000 21:54:47 +0200 From: Jeroen Ruigrok/Asmodai To: Christophe Prevotaux Cc: freebsd-net@freebsd.org, wpaul@freebsd.org Subject: Re: your mail Message-ID: <20000615215447.H3659@daemon.ninth-circle.org> References: <200006051334.PAA05402@proton.hexanet.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200006051334.PAA05402@proton.hexanet.fr>; from chris@hexanet.fr on Mon, Jun 05, 2000 at 03:34:51PM +0200 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -On [20000605 16:02], Christophe Prevotaux (chris@hexanet.fr) wrote: >I bought some DLINK DFE 530 TX Ethernet boards >(the one with the Wake on LAN function ). These >cards are not recognized by FreeBSD 4-STABLE > >I had previously bought the same cards with no WAKE ON LAN >function and they worked just fine. Mail me the results of pciconf -l please. With the card in the PC of course. Thanks, -- Jeroen Ruigrok vd Werven/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best The BSD Programmer's Documentation Project Necessity relieves us of the ordeal of choice... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 15 13:34:59 2000 Delivered-To: freebsd-net@freebsd.org Received: from lunatic.oneinsane.net (lunatic.oneinsane.net [207.113.133.231]) by hub.freebsd.org (Postfix) with ESMTP id 6F04E37B5AA for ; Thu, 15 Jun 2000 13:34:56 -0700 (PDT) (envelope-from insane@lunatic.oneinsane.net) Received: by lunatic.oneinsane.net (Postfix, from userid 1000) id 4D3085DC7; Thu, 15 Jun 2000 13:34:55 -0700 (PDT) Date: Thu, 15 Jun 2000 13:34:54 -0700 From: Ron 'The InSaNe One' Rosson To: freebsd-net@freebsd.org Subject: ppp -nat or ppp with ipf's ipnat ?? Message-ID: <20000615133454.A98489@lunatic.oneinsane.net> Reply-To: Ron Rosson Mail-Followup-To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i X-Operating-System: FreeBSD lunatic.oneinsane.net 4.0-STABLE X-Moon: The Moon is Waxing Gibbous (99% of Full) X-Opinion: What you read here is my IMHO X-Disclaimer: I am a firm believer in RTFM X-WWW: http://www.oneinsane.net X-PGP-KEY: http://www.oneinsane.net/~insane/insane2-pgp5i.txt X-Uptime: 1:30PM up 4 days, 21:46, 1 user, load averages: 0.04, 0.01, 0.00 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I hope I have the correct mailing lists. ;-) I am building a simple straight forward machine fro a friend. Here is what it is going to do. Connect to the internet via a dial-up modem Assign IP's to the LAN using DHCP Provide internet access for the lan by using NAT -- The Delimma -- What is the better way of doing this? - Use the builtin NAT in user-ppp - Use IPFilter's ipnat TIA -- ------------------------------------------------------------------------------ Ron Rosson ... and a UNIX user said ... The InSaNe One rm -rf * insane@oneinsane.net and all was /dev/null and *void() ------------------------------------------------------------------------------ This isn't Burger King. You can't have it your way. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 15 14:26:15 2000 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id B5D3F37B5D8 for ; Thu, 15 Jun 2000 14:26:08 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.9.3/8.9.3) with ESMTP id WAA00631; Thu, 15 Jun 2000 22:21:10 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id WAA02311; Thu, 15 Jun 2000 22:21:16 +0100 (BST) (envelope-from brian@Awfulhak.org) Message-Id: <200006152121.WAA02311@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Ron Rosson Cc: freebsd-net@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: ppp -nat or ppp with ipf's ipnat ?? In-Reply-To: Message from "Ron 'The InSaNe One' Rosson" of "Thu, 15 Jun 2000 13:34:54 PDT." <20000615133454.A98489@lunatic.oneinsane.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Jun 2000 22:21:16 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If you're using ppp(8), use the -nat switch. > I hope I have the correct mailing lists. ;-) > > I am building a simple straight forward machine fro a friend. Here is > what it is going to do. > Connect to the internet via a dial-up modem > Assign IP's to the LAN using DHCP > Provide internet access for the lan by using NAT > -- The Delimma -- > What is the better way of doing this? > - Use the builtin NAT in user-ppp > - Use IPFilter's ipnat > > TIA > -- > ------------------------------------------------------------------------------ > Ron Rosson ... and a UNIX user said ... > The InSaNe One rm -rf * > insane@oneinsane.net and all was /dev/null and *void() > ------------------------------------------------------------------------------ > This isn't Burger King. You can't have it your way. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 15 15:23:57 2000 Delivered-To: freebsd-net@freebsd.org Received: from modemcable127.61-201-24.mtl.mc.videotron.net (modemcable127.61-201-24.mtl.mc.videotron.net [24.201.61.127]) by hub.freebsd.org (Postfix) with SMTP id D638E37B8F3 for ; Thu, 15 Jun 2000 15:23:49 -0700 (PDT) (envelope-from patrick@mindstep.com) Received: (qmail 15677 invoked from network); 15 Jun 2000 22:23:40 -0000 Received: from patrak.local.mindstep.com (HELO PATRAK) (192.168.10.4) by jacuzzi.local.mindstep.com with SMTP; 15 Jun 2000 22:23:40 -0000 Message-ID: <010701bfd718$5917c460$040aa8c0@local.mindstep.com> From: "Patrick Bihan-Faou" To: "David Gilbert" Cc: References: <14664.60992.300592.147710@trooper.velocet.net> Subject: Re: "frag-anyways" knob. Date: Thu, 15 Jun 2000 18:23:36 -0400 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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Is your problem related to the PPPoE bug that some people face where windows machine behind a NAT FreeBSD box seem to not be able to reach some web sites but do fine with others ? I have a friend who has that exact problem, all the packets get out no problem, but some don't come back because they are too big and the telco silently drops them. The easy fix is to set the MTU for windows to be something smaller than the MTU of the PPPoE link (somewhere around 1400). This has the effect of setting the MSS option in outbound TCP packets to something that the PPPoE link can handle. The server then honors that value and no fragmentation occurs. I am working on a patch for natd/libalias that modifies the MSS option for outbound TCP packets and sets that to a value acceptable for the PPPoE link. This means that you don't have to temper with the configuration of the machines on the local network and that the remote sites know what MTU you can handle (at the telco end). This is a hack in as much as the behaviour of some routers that you can't control is broken (not sending back the need frag indication or filtering them), but I believe that it should work. I am currently testing the hack at my friends place, once I get it working I'll submit the patch. Let me know if you want to use it. Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 15 17:30:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by hub.freebsd.org (Postfix) with ESMTP id A2CEE37B8FA for ; Thu, 15 Jun 2000 17:30:08 -0700 (PDT) (envelope-from ino-waiting@gmx.net) Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout1.freenet.de with esmtp (Exim 3.14 #3) id 132k1O-0000rn-00 for freebsd-net@freebsd.org; Fri, 16 Jun 2000 02:30:06 +0200 Received: from [213.6.12.26] (helo=spotteswoode.de) by mx3.freenet.de with smtp (Exim 3.14 #3) id 132k1N-0000xP-00 for freebsd-net@freebsd.org; Fri, 16 Jun 2000 02:30:05 +0200 Received: (qmail 818 invoked by uid 0); 16 Jun 2000 00:30:28 -0000 From: "clemensF" Date: Fri, 16 Jun 2000 02:30:28 +0200 To: Patrick Bihan-Faou Cc: David Gilbert , freebsd-net@freebsd.org Subject: Re: "frag-anyways" knob. Message-ID: <20000616023028.B745@spotteswoode.de> References: <14664.60992.300592.147710@trooper.velocet.net> <010701bfd718$5917c460$040aa8c0@local.mindstep.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010701bfd718$5917c460$040aa8c0@local.mindstep.com>; from patrick@mindstep.com on Thu, Jun 15, 2000 at 06:23:36PM -0400 Organization: private X-PGP-ID: 0xD4685B88-4894C483/DH X-PGP-FPR: 0FAE 5F53 CEB9 49DE 9300 3035 D468 5B88 4894 C483 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Patrick Bihan-Faou: > The easy fix is to set the MTU for windows to be something smaller than the > MTU of the PPPoE link (somewhere around 1400). This has the effect of > setting the MSS option in outbound TCP packets to something that the PPPoE > link can handle. The server then honors that value and no fragmentation > occurs. this problem looks entirely different from a leaf node. but nevertheless i wonder if tcp-flags set by a leaf influences the situation upstream. my throughput is optimal at about 300, but for me it's better to set mru. clemens To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 15 19:12:46 2000 Delivered-To: freebsd-net@freebsd.org Received: from sabre.velocet.net (sabre.velocet.net [198.96.118.66]) by hub.freebsd.org (Postfix) with ESMTP id 283E537B68C for ; Thu, 15 Jun 2000 19:12:40 -0700 (PDT) (envelope-from dgilbert@office.tor.velocet.net) Received: from office.tor.velocet.net (trooper.velocet.net [216.126.82.226]) by sabre.velocet.net (Postfix) with ESMTP id 3842E137FBE; Thu, 15 Jun 2000 22:12:38 -0400 (EDT) Received: (from dgilbert@localhost) by office.tor.velocet.net (8.9.3/8.9.3) id WAA54608; Thu, 15 Jun 2000 22:12:38 -0400 (EDT) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14665.36117.612647.826276@trooper.velocet.net> Date: Thu, 15 Jun 2000 22:12:37 -0400 (EDT) To: "Patrick Bihan-Faou" Cc: "David Gilbert" , Subject: Re: "frag-anyways" knob. In-Reply-To: <010701bfd718$5917c460$040aa8c0@local.mindstep.com> References: <14664.60992.300592.147710@trooper.velocet.net> <010701bfd718$5917c460$040aa8c0@local.mindstep.com> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>> "Patrick" == Patrick Bihan-Faou writes: Patrick> Hi, Is your problem related to the PPPoE bug that some people Patrick> face where windows machine behind a NAT FreeBSD box seem to Patrick> not be able to reach some web sites but do fine with others ? This is related (we have to deal with PPPoE as well), but there are other technologies (VLAN and ATM) that are causing us heartburn at the momment. Patrick> I am working on a patch for natd/libalias that modifies the Patrick> MSS option for outbound TCP packets and sets that to a value Patrick> acceptable for the PPPoE link. This means that you don't Our experience is that not all TCP stacks are listening to MSS. Still other applications (many online games) _depend_ on 1500 byte packets. I think that the MSS hack is cool --- it would definately address the small drop in efficiency that frag-anyways would create, but I still believe the frag-anyways to be necessary due to the number of broken protocols out there. Patrick> I am currently testing the hack at my friends place, once I Patrick> get it working I'll submit the patch. Let me know if you want Patrick> to use it. I would appretiate a copy, yes. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | 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 Jun 15 23:16:33 2000 Delivered-To: freebsd-net@freebsd.org Received: from jason.argos.org (a1-3b058.neo.rr.com [24.93.181.58]) by hub.freebsd.org (Postfix) with ESMTP id 1414137BC45 for ; Thu, 15 Jun 2000 23:16:30 -0700 (PDT) (envelope-from mike@argos.org) Received: from localhost (mike@localhost) by jason.argos.org (8.9.1/8.9.1) with ESMTP id CAA18775; Fri, 16 Jun 2000 02:16:04 -0400 Date: Fri, 16 Jun 2000 02:16:04 -0400 (EDT) From: Mike Nowlin To: Brian Olson Cc: freebsd-net@FreeBSD.ORG Subject: Re: help! In-Reply-To: <39478C4D.34DF02D8@pitel.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I'm trying to configure a FreeBSD 3.4 machine to run Samba and NATD > I have installed Samba and it works great. However, when I install the > second NIC for NATD, the SMB daemon refuses to run. My understanding > is that the "INTERFACES" parameter in smb.conf needs to be set to the > ip of the internal network interface and also to 127.0.0.1 and the "BIND > INTERFACE ONLY" parameter set to "YES". I have done these things and > yet the SMB daemon refuses to run. Any help would be appreciated. Haven't had any problems with mine: (from smb.conf, Samba 2.0.3) interfaces = 10.96.1.1/24 38.153.104.195/29 38.153.104.201/29 (pointing to interfaces fxp1, fxp0, and pn0, in that order) --mike - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Understated/funny man-page sentence of the current time period: From route(4) on FreeBSD-3.4, DESCRIPTION section: "FreeBSD provides some packet routing facilities." ...duh....... Mike Nowlin, N8NVW mike@argos.org http://www.viewsnet.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 16 1:13:11 2000 Delivered-To: freebsd-net@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 9E17437BA9B; Fri, 16 Jun 2000 01:13:02 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (hak.nat.Awfulhak.org [172.31.0.12]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id JAA34807; Fri, 16 Jun 2000 09:12:59 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id JAA01790; Fri, 16 Jun 2000 09:12:56 +0100 (BST) (envelope-from brian@Awfulhak.org) Message-Id: <200006160812.JAA01790@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Patrick Bihan-Faou" Cc: "David Gilbert" , freebsd-net@FreeBSD.org, brian@hak.lan.Awfulhak.org, Ruslan Ermilov Subject: Re: "frag-anyways" knob. In-Reply-To: Message from "Patrick Bihan-Faou" of "Thu, 15 Jun 2000 18:23:36 EDT." <010701bfd718$5917c460$040aa8c0@local.mindstep.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Jun 2000 09:12:56 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [.....] > I am working on a patch for natd/libalias that modifies the MSS option for > outbound TCP packets and sets that to a value acceptable for the PPPoE link. [.....] > I am currently testing the hack at my friends place, once I get it working > I'll submit the patch. Let me know if you want to use it. I'm definitely interested in this too. Can you stick me on the review list ? > Patrick. Cheers. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 16 6:15:33 2000 Delivered-To: freebsd-net@freebsd.org Received: from sasi.com (sasi.com [164.164.56.2]) by hub.freebsd.org (Postfix) with ESMTP id E5B4337BE69 for ; Fri, 16 Jun 2000 06:15:07 -0700 (PDT) (envelope-from deepika@sasi.com) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id SAA28824 for ; Fri, 16 Jun 2000 18:43:19 +0530 (IST) Received: from hpd14.sasi.com ([10.0.16.14]) by sasi.com; Fri, 16 Jun 2000 18:43:18 +0000 (IST) Received: from localhost (deepika@localhost) by hpd14.sasi.com (8.9.1/8.9.1) with ESMTP id SAA10254 for ; Fri, 16 Jun 2000 18:56:00 +0530 (IST) Date: Fri, 16 Jun 2000 18:56:00 +0530 (IST) From: Deepika Kakrania To: freebsd-net@FreeBSD.ORG Subject: unsubscribe Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org unsubscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 16 7: 6:36 2000 Delivered-To: freebsd-net@freebsd.org Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by hub.freebsd.org (Postfix) with ESMTP id CBF9537BDAE for ; Fri, 16 Jun 2000 07:06:31 -0700 (PDT) (envelope-from ino-waiting@gmx.net) Received: from [62.104.201.2] (helo=mx1.freenet.de) by mout1.freenet.de with esmtp (Exim 3.14 #3) id 132wlS-0005rV-00 for freebsd-net@freebsd.org; Fri, 16 Jun 2000 16:06:30 +0200 Received: from [213.6.3.2] (helo=spotteswoode.de) by mx1.freenet.de with smtp (Exim 3.14 #3) id 132wlR-0001H6-00 for freebsd-net@FreeBSD.org; Fri, 16 Jun 2000 16:06:30 +0200 Received: (qmail 5976 invoked by uid 0); 16 Jun 2000 14:06:23 -0000 From: "clemensF" Date: Fri, 16 Jun 2000 16:06:23 +0200 To: freebsd-net@FreeBSD.org Subject: Re: "frag-anyways" knob. Message-ID: <20000616160623.A5968@spotteswoode.de> Mail-Followup-To: freebsd-net@FreeBSD.org References: <200006160812.JAA01790@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200006160812.JAA01790@hak.lan.Awfulhak.org>; from brian@Awfulhak.org on Fri, Jun 16, 2000 at 09:12:56AM +0100 Organization: private X-PGP-ID: 0xD4685B88-4894C483/DH X-PGP-FPR: 0FAE 5F53 CEB9 49DE 9300 3035 D468 5B88 4894 C483 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Brian Somers: > I'm definitely interested in this too. Can you stick me on the > review list ? this should definitely be published. dont forget us!!! clemens To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 16 8:23: 7 2000 Delivered-To: freebsd-net@freebsd.org Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by hub.freebsd.org (Postfix) with ESMTP id 83E6D37C038 for ; Fri, 16 Jun 2000 08:22:44 -0700 (PDT) (envelope-from DRHAGER@de.ibm.com) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id RAA200390; Fri, 16 Jun 2000 17:22:39 +0200 From: DRHAGER@de.ibm.com Received: from d12mta01.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.8.8m3/NCO v2.07) with SMTP id RAA20880; Fri, 16 Jun 2000 17:22:27 +0200 Received: by d12mta01.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256900.00422A1C ; Fri, 16 Jun 2000 14:02:41 +0200 X-Lotus-FromDomain: IBMDE To: "IT Department" Cc: net@FreeBSD.ORG Message-ID: Date: Fri, 16 Jun 2000 14:01:52 +0200 Subject: Re: Deleteing no permanent routes from my routing tables. Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Interesting idea sending this to freebsd.org ;-) UGHDM means that this route is used, its via a gateway, its to a host, its added dynamically and has been modified. Your network has better ideas about routing than you put in your routing table, so the routes are modified either by a routing deamon or by icmp redirects. You can delete them by route delete . They will reappear when the cause persists. Are you running a routing deamon? (lssrc -a, ps -ef) Could this be by accident? There could be some misconfigured host; try to run "route monitor" and have a look whos changing the routes. You can disable receiving and sending of icmp redirects *if you know what you do* via the "no" command. -Orm Sir, I hope you can help, but I have a number of routes defined when I do a netstat -r command (aix 4.3) there are a number that have the flag UGHDM which I understand means that they are routes that are only temporary i.e dynamic, firstly is this correct and secondly how can I remove these entries without having to reboot? I can use the route -f command, but I think that this will clear ALL routes that I have defined.This I do not want to do..... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 16 8:42:36 2000 Delivered-To: freebsd-net@freebsd.org Received: from mercury.spvi.com (h194.spvi.com [208.150.70.194]) by hub.freebsd.org (Postfix) with ESMTP id D9AEB37BF0C; Fri, 16 Jun 2000 08:42:12 -0700 (PDT) (envelope-from steve@mercury.spvi.com) Received: (from steve@localhost) by mercury.spvi.com (8.9.3/8.9.3) id KAA05858; Fri, 16 Jun 2000 10:39:23 -0500 (EST) (envelope-from steve) Date: Fri, 16 Jun 2000 10:39:23 -0500 (EST) Message-Id: <200006161539.KAA05858@mercury.spvi.com> From: Steve Spicklemire To: freebsd-stable@freebsd.org, freebsd-net@freebsd.org Cc: steve@spvi.com Subject: mpd, pptp, VPN etc.... Reply-To: steve@spvi.com Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Folks, This is really frustrating! This worked a couple of weeks ago, but now it's failing. I'm not sure when it started failing since I don't use this stuff much (Hell.. I *wish* there were no such thing as Windows, then we wouldn't *need* it.. but there's nothing for it...) I had a working mpd/pptp/M$/VPN setup a few weeks ago.. tested it... was happy. Then, to my amazement, when I tried to install the same system on my client's system... it failed! Now.. I go back to my own system.. and it fails! I've copied everything I can think that might matter below. It looks like it should *work* but I can't ping from 10.0.0.1 to 10.0.0.2 when this thing is running.... Here's what I'm trying: remote network: FreeBSD 4.0s 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 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.1/32 10.0.0.2/32 set ipcp dns 192.146.191.13 # If you wanted MPPE encryption and had ng_mppc(8)... set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set bundle enable crypt-reqd set ccp yes mpp-stateless ---------------------------------------------------------------------- Local system: Win98 VPN adaptor mpd.log says: Jun 15 10:20:10 radio mpd: mpd: pid 29701, version 3.0b7 (root@radio.uindy.edu 19:13 18-May-2000) Jun 15 10:20:10 radio mpd: [pptp] ppp node is "mpd29701-pptp" Jun 15 10:20:10 radio mpd: [pptp] using interface ng0 Jun 15 10:20:10 radio mpd: mpd: local IP address for PPTP is 192.146.191.22 Jun 15 10:20:43 radio mpd: mpd: PPTP connection from 208.150.70.202:1032 Jun 15 10:20:43 radio mpd: pptp0: attached to connection with 208.150.70.202:1032 Jun 15 10:20:43 radio mpd: [pptp] IFACE: Open event Jun 15 10:20:43 radio mpd: [pptp] IPCP: Open event Jun 15 10:20:43 radio mpd: [pptp] IPCP: state change Initial --> Starting Jun 15 10:20:43 radio mpd: [pptp] IPCP: LayerStart Jun 15 10:20:43 radio mpd: [pptp] IPCP: Open event Jun 15 10:20:43 radio mpd: [pptp] bundle: OPEN event in state CLOSED Jun 15 10:20:43 radio mpd: [pptp] opening link "pptp"... Jun 15 10:20:43 radio mpd: [pptp] link: OPEN event Jun 15 10:20:43 radio mpd: [pptp] LCP: Open event Jun 15 10:20:43 radio mpd: [pptp] LCP: state change Initial --> Starting Jun 15 10:20:43 radio mpd: [pptp] LCP: LayerStart Jun 15 10:20:43 radio mpd: [pptp] device: OPEN event in state DOWN Jun 15 10:20:43 radio mpd: [pptp] attaching to peer's outgoing call Jun 15 10:20:43 radio mpd: [pptp] device is now in state OPENING Jun 15 10:20:43 radio mpd: [pptp] device: UP event in state OPENING Jun 15 10:20:43 radio mpd: [pptp] device is now in state UP Jun 15 10:20:43 radio mpd: [pptp] link: UP event Jun 15 10:20:43 radio mpd: [pptp] link: origination is remote Jun 15 10:20:43 radio mpd: [pptp] LCP: Up event Jun 15 10:20:43 radio mpd: [pptp] LCP: state change Starting --> Req-Sent Jun 15 10:20:43 radio mpd: [pptp] LCP: phase shift DEAD --> ESTABLISH Jun 15 10:20:43 radio mpd: [pptp] LCP: SendConfigReq #1 Jun 15 10:20:43 radio mpd: ACFCOMP Jun 15 10:20:43 radio mpd: PROTOCOMP Jun 15 10:20:43 radio mpd: MRU 1500 Jun 15 10:20:43 radio mpd: MAGICNUM 256f3566 Jun 15 10:20:43 radio mpd: AUTHPROTO CHAP MSOFT Jun 15 10:20:43 radio mpd: [pptp] LCP: rec'd Configure Request #1 link 0 (Req-Sent) Jun 15 10:20:43 radio mpd: ACCMAP 0x000a0000 Jun 15 10:20:43 radio mpd: MAGICNUM 00030b46 Jun 15 10:20:43 radio mpd: PROTOCOMP Jun 15 10:20:43 radio mpd: ACFCOMP Jun 15 10:20:43 radio mpd: CALLBACK Jun 15 10:20:43 radio mpd: Not supported Jun 15 10:20:43 radio mpd: [pptp] LCP: SendConfigRej #1 Jun 15 10:20:43 radio mpd: CALLBACK Jun 15 10:20:43 radio mpd: [pptp] error writing len 11 frame to bypass: No buffer space available Jun 15 10:20:45 radio mpd: [pptp] LCP: SendConfigReq #2 Jun 15 10:20:45 radio mpd: ACFCOMP Jun 15 10:20:45 radio mpd: PROTOCOMP Jun 15 10:20:45 radio mpd: MRU 1500 Jun 15 10:20:45 radio mpd: MAGICNUM 256f3566 Jun 15 10:20:45 radio mpd: AUTHPROTO CHAP MSOFT Jun 15 10:20:45 radio mpd: [pptp] error writing len 27 frame to bypass: No buffer space available Jun 15 10:20:47 radio mpd: [pptp] LCP: SendConfigReq #3 Jun 15 10:20:47 radio mpd: ACFCOMP Jun 15 10:20:47 radio mpd: PROTOCOMP Jun 15 10:20:47 radio mpd: MRU 1500 Jun 15 10:20:47 radio mpd: MAGICNUM 256f3566 Jun 15 10:20:47 radio mpd: AUTHPROTO CHAP MSOFT Jun 15 10:20:47 radio mpd: [pptp] error writing len 27 frame to bypass: No buffer space available Jun 15 10:20:47 radio mpd: [pptp] LCP: rec'd Configure Request #2 link 0 (Req-Sent) Jun 15 10:20:47 radio mpd: ACCMAP 0x000a0000 Jun 15 10:20:47 radio mpd: MAGICNUM 00030b46 Jun 15 10:20:47 radio mpd: PROTOCOMP Jun 15 10:20:47 radio mpd: ACFCOMP Jun 15 10:20:47 radio mpd: CALLBACK Jun 15 10:20:47 radio mpd: Not supported Jun 15 10:20:47 radio mpd: [pptp] LCP: SendConfigRej #2 Jun 15 10:20:47 radio mpd: CALLBACK Jun 15 10:20:47 radio mpd: [pptp] error writing len 11 frame to bypass: No buffer space available Jun 15 10:20:49 radio mpd: [pptp] LCP: SendConfigReq #4 Jun 15 10:20:49 radio mpd: ACFCOMP Jun 15 10:20:49 radio mpd: PROTOCOMP Jun 15 10:20:49 radio mpd: MRU 1500 Jun 15 10:20:49 radio mpd: MAGICNUM 256f3566 Jun 15 10:20:49 radio mpd: AUTHPROTO CHAP MSOFT Jun 15 10:20:49 radio mpd: [pptp] error writing len 27 frame to bypass: No buffer space available Jun 15 10:20:50 radio mpd: [pptp] LCP: rec'd Configure Request #3 link 0 (Req-Sent) Jun 15 10:20:50 radio mpd: ACCMAP 0x000a0000 Jun 15 10:20:50 radio mpd: MAGICNUM 00030b46 Jun 15 10:20:50 radio mpd: PROTOCOMP Jun 15 10:20:50 radio mpd: ACFCOMP Jun 15 10:20:50 radio mpd: CALLBACK Jun 15 10:20:50 radio mpd: Not supported Jun 15 10:20:50 radio mpd: [pptp] LCP: SendConfigRej #3 Jun 15 10:20:50 radio mpd: CALLBACK Jun 15 10:20:50 radio mpd: [pptp] error writing len 11 frame to bypass: No buffer space available Jun 15 10:20:51 radio mpd: [pptp] LCP: SendConfigReq #5 Jun 15 10:20:51 radio mpd: ACFCOMP Jun 15 10:20:51 radio mpd: PROTOCOMP Jun 15 10:20:51 radio mpd: MRU 1500 Jun 15 10:20:51 radio mpd: MAGICNUM 256f3566 Jun 15 10:20:51 radio mpd: AUTHPROTO CHAP MSOFT Jun 15 10:20:51 radio mpd: [pptp] error writing len 27 frame to bypass: No buffer space available Jun 15 10:20:53 radio mpd: [pptp] LCP: SendConfigReq #6 Jun 15 10:20:53 radio mpd: ACFCOMP Jun 15 10:20:53 radio mpd: PROTOCOMP Jun 15 10:20:53 radio mpd: MRU 1500 Jun 15 10:20:53 radio mpd: MAGICNUM 256f3566 Jun 15 10:20:53 radio mpd: AUTHPROTO CHAP MSOFT Jun 15 10:20:53 radio mpd: [pptp] LCP: rec'd Configure Request #4 link 0 (Req-Sent) Jun 15 10:20:53 radio mpd: ACCMAP 0x000a0000 Jun 15 10:20:53 radio mpd: MAGICNUM 00030b46 Jun 15 10:20:53 radio mpd: PROTOCOMP Jun 15 10:20:53 radio mpd: ACFCOMP Jun 15 10:20:53 radio mpd: CALLBACK Jun 15 10:20:53 radio mpd: Not supported Jun 15 10:20:53 radio mpd: [pptp] LCP: SendConfigRej #4 Jun 15 10:20:53 radio mpd: CALLBACK Jun 15 10:20:53 radio mpd: [pptp] LCP: rec'd Configure Ack #6 link 0 (Req-Sent) Jun 15 10:20:53 radio mpd: ACFCOMP Jun 15 10:20:53 radio mpd: PROTOCOMP Jun 15 10:20:53 radio mpd: MRU 1500 Jun 15 10:20:53 radio mpd: MAGICNUM 256f3566 Jun 15 10:20:53 radio mpd: AUTHPROTO CHAP MSOFT Jun 15 10:20:53 radio mpd: [pptp] LCP: state change Req-Sent --> Ack-Rcvd Jun 15 10:20:53 radio mpd: [pptp] LCP: rec'd Configure Request #5 link 0 (Ack-Rcvd) Jun 15 10:20:53 radio mpd: ACCMAP 0x000a0000 Jun 15 10:20:53 radio mpd: MAGICNUM 00030b46 Jun 15 10:20:53 radio mpd: PROTOCOMP Jun 15 10:20:53 radio mpd: ACFCOMP Jun 15 10:20:53 radio mpd: [pptp] LCP: SendConfigAck #5 Jun 15 10:20:53 radio mpd: ACCMAP 0x000a0000 Jun 15 10:20:53 radio mpd: MAGICNUM 00030b46 Jun 15 10:20:53 radio mpd: PROTOCOMP Jun 15 10:20:53 radio mpd: ACFCOMP Jun 15 10:20:53 radio mpd: [pptp] LCP: state change Ack-Rcvd --> Opened Jun 15 10:20:53 radio mpd: [pptp] LCP: phase shift ESTABLISH --> AUTHENTICATE Jun 15 10:20:53 radio mpd: [pptp] LCP: auth: peer wants nothing, I want CHAP Jun 15 10:20:53 radio mpd: [pptp] CHAP: sending CHALLENGE Jun 15 10:20:53 radio mpd: [pptp] LCP: LayerUp Jun 15 10:20:54 radio mpd: [pptp] CHAP: rec'd RESPONSE #1 Jun 15 10:20:54 radio mpd: Name: "steve" Jun 15 10:20:54 radio mpd: Peer name: "steve" Jun 15 10:20:54 radio mpd: Response is valid Jun 15 10:20:54 radio mpd: [pptp] CHAP: sending SUCCESS Jun 15 10:20:54 radio mpd: [pptp] LCP: authorization successful Jun 15 10:20:54 radio mpd: [pptp] LCP: phase shift AUTHENTICATE --> NETWORK Jun 15 10:20:54 radio mpd: [pptp] up: 1 link, total bandwidth 64000 bps Jun 15 10:20:54 radio mpd: [pptp] IPCP: Up event Jun 15 10:20:54 radio mpd: [pptp] IPCP: state change Starting --> Req-Sent Jun 15 10:20:54 radio mpd: [pptp] IPCP: SendConfigReq #1 Jun 15 10:20:54 radio mpd: IPADDR 10.0.0.1 Jun 15 10:20:54 radio mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jun 15 10:20:54 radio mpd: [pptp] CCP: Open event Jun 15 10:20:54 radio mpd: [pptp] CCP: state change Initial --> Starting Jun 15 10:20:54 radio mpd: [pptp] CCP: LayerStart Jun 15 10:20:54 radio mpd: [pptp] CCP: Up event Jun 15 10:20:54 radio mpd: [pptp] CCP: state change Starting --> Req-Sent Jun 15 10:20:54 radio mpd: [pptp] CCP: SendConfigReq #1 Jun 15 10:20:56 radio mpd: [pptp] IPCP: SendConfigReq #2 Jun 15 10:20:56 radio mpd: IPADDR 10.0.0.1 Jun 15 10:20:56 radio mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jun 15 10:20:56 radio mpd: [pptp] CCP: SendConfigReq #2 Jun 15 10:20:56 radio mpd: [pptp] error writing len 14 frame to bypass: No buffer space available Jun 15 10:20:58 radio mpd: [pptp] IPCP: SendConfigReq #3 Jun 15 10:20:58 radio mpd: IPADDR 10.0.0.1 Jun 15 10:20:58 radio mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jun 15 10:20:58 radio mpd: [pptp] CCP: SendConfigReq #3 Jun 15 10:20:59 radio mpd: [pptp] CHAP: rec'd RESPONSE #1 Jun 15 10:20:59 radio mpd: Not expected, but that's OK Jun 15 10:20:59 radio mpd: Name: "steve" Jun 15 10:20:59 radio mpd: Peer name: "steve" Jun 15 10:20:59 radio mpd: Response is valid Jun 15 10:20:59 radio mpd: [pptp] CHAP: sending SUCCESS Jun 15 10:20:59 radio mpd: [pptp] LCP: authorization successful Jun 15 10:20:59 radio mpd: [pptp] IPCP: rec'd Configure Request #1 link 0 (Req-Sent) Jun 15 10:20:59 radio mpd: COMPPROTO VJCOMP, 16 comp. channels, allow comp-cid Jun 15 10:20:59 radio mpd: IPADDR 0.0.0.0 Jun 15 10:20:59 radio mpd: NAKing with 10.0.0.2 Jun 15 10:20:59 radio mpd: PRIDNS 0.0.0.0 Jun 15 10:20:59 radio mpd: NAKing with 192.146.191.13 Jun 15 10:20:59 radio mpd: PRINBNS 0.0.0.0 Jun 15 10:20:59 radio mpd: SECDNS 0.0.0.0 Jun 15 10:20:59 radio mpd: SECNBNS 0.0.0.0 Jun 15 10:20:59 radio mpd: [pptp] IPCP: SendConfigRej #1 Jun 15 10:20:59 radio mpd: PRINBNS 0.0.0.0 Jun 15 10:20:59 radio mpd: SECDNS 0.0.0.0 Jun 15 10:20:59 radio mpd: SECNBNS 0.0.0.0 Jun 15 10:20:59 radio mpd: [pptp] CCP: rec'd Configure Request #1 link 0 (Req-Sent) Jun 15 10:20:59 radio mpd: [pptp] CCP: SendConfigNak #1 Jun 15 10:21:00 radio mpd: [pptp] IPCP: SendConfigReq #4 Jun 15 10:21:00 radio mpd: IPADDR 10.0.0.1 Jun 15 10:21:00 radio mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jun 15 10:21:00 radio mpd: [pptp] CCP: SendConfigReq #4 Jun 15 10:21:00 radio mpd: [pptp] error writing len 14 frame to bypass: No buffer space available Jun 15 10:21:00 radio mpd: [pptp] IPCP: rec'd Configure Ack #4 link 0 (Req-Sent) Jun 15 10:21:00 radio mpd: IPADDR 10.0.0.1 Jun 15 10:21:00 radio mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jun 15 10:21:00 radio mpd: [pptp] IPCP: state change Req-Sent --> Ack-Rcvd Jun 15 10:21:02 radio mpd: [pptp] CCP: SendConfigReq #5 Jun 15 10:21:02 radio mpd: [pptp] CCP: rec'd Configure Nak #5 link 0 (Req-Sent) Jun 15 10:21:02 radio mpd: [pptp] CCP: SendConfigReq #6 Jun 15 10:21:02 radio mpd: [pptp] CCP: rec'd Configure Ack #6 link 0 (Req-Sent) Jun 15 10:21:02 radio mpd: [pptp] CCP: state change Req-Sent --> Ack-Rcvd Jun 15 10:21:02 radio mpd: [pptp] CCP: rec'd Configure Request #2 link 0 (Ack-Rcvd) Jun 15 10:21:02 radio mpd: [pptp] CCP: SendConfigNak #2 Jun 15 10:21:02 radio mpd: [pptp] IPCP: rec'd Configure Request #2 link 0 (Ack-Rcvd) Jun 15 10:21:02 radio mpd: COMPPROTO VJCOMP, 16 comp. channels, allow comp-cid Jun 15 10:21:02 radio mpd: IPADDR 0.0.0.0 Jun 15 10:21:02 radio mpd: NAKing with 10.0.0.2 Jun 15 10:21:02 radio mpd: PRIDNS 0.0.0.0 Jun 15 10:21:02 radio mpd: NAKing with 192.146.191.13 Jun 15 10:21:02 radio mpd: PRINBNS 0.0.0.0 Jun 15 10:21:02 radio mpd: SECDNS 0.0.0.0 Jun 15 10:21:02 radio mpd: SECNBNS 0.0.0.0 Jun 15 10:21:02 radio mpd: [pptp] IPCP: SendConfigRej #2 Jun 15 10:21:02 radio mpd: PRINBNS 0.0.0.0 Jun 15 10:21:02 radio mpd: SECDNS 0.0.0.0 Jun 15 10:21:02 radio mpd: SECNBNS 0.0.0.0 Jun 15 10:21:02 radio mpd: [pptp] CCP: rec'd Configure Request #3 link 0 (Ack-Rcvd) Jun 15 10:21:02 radio mpd: [pptp] CCP: SendConfigAck #3 Jun 15 10:21:02 radio mpd: [pptp] CCP: state change Ack-Rcvd --> Opened Jun 15 10:21:02 radio mpd: [pptp] CCP: LayerUp Jun 15 10:21:02 radio mpd: [pptp] can't create mppc node: Device not configured Jun 15 10:21:02 radio mpd: [pptp] CCP: parameter negotiation failed Jun 15 10:21:02 radio mpd: [pptp] CCP: Close event Jun 15 10:21:02 radio mpd: [pptp] CCP: state change Opened --> Closing Jun 15 10:21:02 radio mpd: [pptp] CCP: SendTerminateReq #7 Jun 15 10:21:02 radio mpd: [pptp] CCP: LayerDown Jun 15 10:21:02 radio mpd: [pptp] CCP: state change Closing --> Closed Jun 15 10:21:02 radio mpd: [pptp] CCP: LayerFinish Jun 15 10:21:02 radio mpd: [pptp] IPCP: rec'd Configure Request #3 link 0 (Ack-Rcvd) Jun 15 10:21:02 radio mpd: COMPPROTO VJCOMP, 16 comp. channels, allow comp-cid Jun 15 10:21:02 radio mpd: IPADDR 0.0.0.0 Jun 15 10:21:02 radio mpd: NAKing with 10.0.0.2 Jun 15 10:21:02 radio mpd: PRIDNS 0.0.0.0 Jun 15 10:21:02 radio mpd: NAKing with 192.146.191.13 Jun 15 10:21:02 radio mpd: [pptp] IPCP: SendConfigNak #3 Jun 15 10:21:02 radio mpd: IPADDR 10.0.0.2 Jun 15 10:21:02 radio mpd: PRIDNS 192.146.191.13 Jun 15 10:21:05 radio mpd: [pptp] IPCP: rec'd Configure Request #4 link 0 (Ack-Rcvd) Jun 15 10:21:05 radio mpd: COMPPROTO VJCOMP, 16 comp. channels, allow comp-cid Jun 15 10:21:05 radio mpd: IPADDR 0.0.0.0 Jun 15 10:21:05 radio mpd: NAKing with 10.0.0.2 Jun 15 10:21:05 radio mpd: PRIDNS 0.0.0.0 Jun 15 10:21:05 radio mpd: NAKing with 192.146.191.13 Jun 15 10:21:05 radio mpd: [pptp] IPCP: SendConfigNak #4 Jun 15 10:21:05 radio mpd: IPADDR 10.0.0.2 Jun 15 10:21:05 radio mpd: PRIDNS 192.146.191.13 Jun 15 10:21:06 radio mpd: [pptp] IPCP: rec'd Configure Request #5 link 0 (Ack-Rcvd) Jun 15 10:21:06 radio mpd: COMPPROTO VJCOMP, 16 comp. channels, allow comp-cid Jun 15 10:21:06 radio mpd: IPADDR 10.0.0.2 Jun 15 10:21:06 radio mpd: 10.0.0.2 is OK Jun 15 10:21:06 radio mpd: PRIDNS 192.146.191.13 Jun 15 10:21:06 radio mpd: [pptp] IPCP: SendConfigAck #5 Jun 15 10:21:06 radio mpd: COMPPROTO VJCOMP, 16 comp. channels, allow comp-cid Jun 15 10:21:06 radio mpd: IPADDR 10.0.0.2 Jun 15 10:21:06 radio mpd: PRIDNS 192.146.191.13 Jun 15 10:21:06 radio mpd: [pptp] IPCP: state change Ack-Rcvd --> Opened Jun 15 10:21:06 radio mpd: [pptp] IPCP: LayerUp Jun 15 10:21:06 radio mpd: 10.0.0.1 -> 10.0.0.2 Jun 15 10:21:06 radio mpd: [pptp] IFACE: Up event Jun 15 10:21:06 radio mpd: [pptp] exec: /sbin/ifconfig ng0 10.0.0.1 10.0.0.2 netmask 0xffffffff -link0 Jun 15 10:21:06 radio mpd: [pptp] exec: /usr/sbin/arp -s 10.0.0.2 48:54:e8:28:e7:a1 pub Jun 15 10:21:07 radio mpd: [pptp] rec'd unexpected protocol COMPD on link 0 Jun 15 10:21:38 radio last message repeated 16 times Jun 15 10:21:41 radio last message repeated 2 times Jun 15 10:21:51 radio mpd: mpd: caught fatal signal int Jun 15 10:21:51 radio mpd: mpd: fatal error, exiting Jun 15 10:21:51 radio mpd: [pptp] IPCP: Down event Jun 15 10:21:51 radio mpd: [pptp] IPCP: state change Opened --> Starting Jun 15 10:21:51 radio mpd: [pptp] IPCP: LayerDown Jun 15 10:21:51 radio mpd: [pptp] IFACE: Down event Jun 15 10:21:51 radio mpd: [pptp] exec: /usr/sbin/arp -d 10.0.0.2 Jun 15 10:21:51 radio mpd: [pptp] exec: /sbin/ifconfig ng0 down delete -link0 Jun 15 10:21:51 radio mpd: [pptp] IFACE: Close event Jun 15 10:21:51 radio mpd: [pptp] IPCP: Close event Jun 15 10:21:51 radio mpd: [pptp] IPCP: state change Starting --> Initial Jun 15 10:21:51 radio mpd: [pptp] IPCP: LayerFinish Jun 15 10:21:51 radio mpd: mpd: process 29701 terminated show link gives: [pptp:pptp] show link Link pptp: Configuration MRU : 1500 bytes Ctrl char map : 0x000a0000 bytes Retry timeout : 2 seconds Max redial : 0 connect attempts Bandwidth : 64000 bits/sec Latency : 2000 usec Keep-alive : every 10 secs, timeout 60 Ident string : "" Link level options Name Self Peer ---------------------------------------- pap disable deny chap enable deny acfcomp enable accept protocomp enable accept magicnum enable passive disable check-magic enable no-orig-auth disable callback disable Traffic stats: Octets input : 1747 Frames input : 33 Octets output : 270 Frames output : 16 Bad protocols : 0 Runts : 0 Dup fragments : 0 Drop fragments : 0 Device specific info: Type : pptp State : UP PPTP status: Connection : UP Peer range : 0.0.0.0/0 Current peer : 208.150.70.202, port 1034 PPTP options: Name Self Peer ---------------------------------------- originate disable incoming enable outcall enable shop cpp gives: [pptp:pptp] show ccp [pptp] CCP [Closed] Enabled protocols: Name Self Peer ---------------------------------------- mppc enable accept mpp-compress disable deny mpp-e40 enable accept mpp-e128 enable accept mpp-stateless enable accept Incoming decompression: Protocol: MPPE, 40 bit, stateless Outgoing compression: Protocol: MPPE, 40 bit, stateless show lcp gives: [pptp:pptp] show lcp LCP [Opened] Self: MRU : 1500 bytes MAGIC : 0x752205a2 ACCMAP : 0x000a0000 ACFCOMP : Yes PROTOCOMP: Yes Peer: MRU : 1500 bytes MAGIC : 0x000e494f ACCMAP : 0x000a0000 ACFCOMP : Yes PROTOCOMP: Yes ifconfig: ed0: flags=8843 mtu 1500 inet 192.146.191.22 netmask 0xffffff00 broadcast 192.146.191.255 inet6 fe80::4a54:e8ff:fe28:e7a1%ed0 prefixlen 64 scopeid 0x1 inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 ether 48:54:e8:28:e7:a1 lp0: flags=8810 mtu 1500 sl0: flags=c010 mtu 552 ppp0: flags=8010 mtu 1500 lo0: flags=8049 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 gif0: flags=8010 mtu 1280 inet6 fe80::4a54:e8ff:fe28:e7a1%gif0 prefixlen 64 scopeid 0x6 gif1: flags=8010 mtu 1280 inet6 fe80::4a54:e8ff:fe28:e7a1%gif1 prefixlen 64 scopeid 0x7 gif2: flags=8010 mtu 1280 inet6 fe80::4a54:e8ff:fe28:e7a1%gif2 prefixlen 64 scopeid 0x8 gif3: flags=8010 mtu 1280 inet6 fe80::4a54:e8ff:fe28:e7a1%gif3 prefixlen 64 scopeid 0x9 stf0: flags=8000 mtu 1280 inet6 fe80::4a54:e8ff:fe28:e7a1%stf0 prefixlen 64 scopeid 0xa faith0: flags=8000 mtu 1500 ng0: flags=88d1 mtu 1498 inet 10.0.0.1 --> 10.0.0.2 netmask 0xffffffff netstat -nr: radio> netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.146.191.2 UGSc 11 573 ed0 10/24 link#1 UC 0 0 ed0 => 10.0.0.2 10.0.0.1 UH 0 0 ng0 10.0.0.2 48:54:e8:28:e7:a1 UHLS2 0 0 ed0 127.0.0.1 127.0.0.1 UH 0 159 lo0 192.146.191 link#1 UC 0 0 ed0 => 192.146.191.2 0:30:19:71:2c:1 UHLW 11 0 ed0 1195 192.146.191.13 0:90:27:5a:fd:66 UHLW 0 24 ed0 1158 192.146.191.22 48:54:e8:28:e7:a1 UHLW 0 248 lo0 tcpdump on remote while pinging from local: radio# tcpdump host 10.0.0.2 tcpdump: listening on ed0 ^C 317 packets received by filter 0 packets dropped by kernel radio# tcpdump host 10.0.0.1 tcpdump: listening on ed0 ^C 386 packets received by filter 0 packets dropped by kernel nothing... but when I ping in either direction... I get: [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 this did not happen when it was working? Is this a 'stable' problem? Or am I doing something else stupid? Thanks for any help! -steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 16 8:51:18 2000 Delivered-To: freebsd-net@freebsd.org Received: from modemcable127.61-201-24.mtl.mc.videotron.net (modemcable127.61-201-24.mtl.mc.videotron.net [24.201.61.127]) by hub.freebsd.org (Postfix) with SMTP id 7C61737BF7A for ; Fri, 16 Jun 2000 08:51:15 -0700 (PDT) (envelope-from patrick@mindstep.com) Received: (qmail 43276 invoked from network); 16 Jun 2000 15:51:14 -0000 Received: from patrak.local.mindstep.com (HELO PATRAK) (192.168.10.4) by jacuzzi.local.mindstep.com with SMTP; 16 Jun 2000 15:51:14 -0000 Message-ID: <013101bfd7aa$b2949f80$040aa8c0@local.mindstep.com> From: "Patrick Bihan-Faou" To: References: <200006160812.JAA01790@hak.lan.Awfulhak.org> <20000616160623.A5968@spotteswoode.de> Subject: Re: "frag-anyways" knob. Date: Fri, 16 Jun 2000 11:51:12 -0400 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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, ----- Original Message ----- From: ""clemensF"" > > Brian Somers: > > > I'm definitely interested in this too. Can you stick me on the > > review list ? > > this should definitely be published. > > dont forget us!!! > Let me do some more testing first, update the patch to the latest versions of libalias, natd and ppp and I will publish them. Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 16 11:43: 3 2000 Delivered-To: freebsd-net@freebsd.org Received: from mercury.spvi.com (h194.spvi.com [208.150.70.194]) by hub.freebsd.org (Postfix) with ESMTP id E7B0D37B6F5; Fri, 16 Jun 2000 11:42:24 -0700 (PDT) (envelope-from steve@mercury.spvi.com) Received: (from steve@localhost) by mercury.spvi.com (8.9.3/8.9.3) id NAA06820; Fri, 16 Jun 2000 13:39:36 -0500 (EST) (envelope-from steve) Date: Fri, 16 Jun 2000 13:39:36 -0500 (EST) Message-Id: <200006161839.NAA06820@mercury.spvi.com> From: Steve Spicklemire To: freebsd-net@freebsd.org, freebsd-questions.org@mercury.spvi.com, freebsd-questions@freebsd.org Cc: steve@spvi.com In-reply-to: <200006161539.KAA05858@mercury.spvi.com> (message from Steve Spicklemire on Fri, 16 Jun 2000 10:39:23 -0500 (EST)) Subject: Re: mpd, pptp, VPN etc.... Reply-To: steve@spvi.com Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi again... Forgot to mention why this might be a 'stable' issue... the only thing I can think of that has changed is a cvsup ->...make world. thanks, -steve earlier I wrote.. ---------------------------------------------------------------------- Hi Folks, This is really frustrating! This worked a couple of weeks ago, but now it's failing. I'm not sure when it started failing since I don't use this stuff much (Hell.. I *wish* there were no such thing as Windows, then we wouldn't *need* it.. but there's nothing for it...) I had a working mpd/pptp/M$/VPN setup a few weeks ago.. tested it... was happy. Then, to my amazement, when I tried to install the same system on my client's system... it failed! Now.. I go back to my own system.. and it fails! I've copied everything I can think that might matter below. It looks like it should *work* but I can't ping from 10.0.0.1 to 10.0.0.2 when this thing is running.... Here's what I'm trying: remote network: FreeBSD 4.0s 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 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.1/32 10.0.0.2/32 set ipcp dns 192.146.191.13 # If you wanted MPPE encryption and had ng_mppc(8)... set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set bundle enable crypt-reqd set ccp yes mpp-stateless ---------------------------------------------------------------------- Local system: Win98 VPN adaptor mpd.log says: Jun 15 10:20:10 radio mpd: mpd: pid 29701, version 3.0b7 (root@radio.uindy.edu 19:13 18-May-2000) Jun 15 10:20:10 radio mpd: [pptp] ppp node is "mpd29701-pptp" Jun 15 10:20:10 radio mpd: [pptp] using interface ng0 Jun 15 10:20:10 radio mpd: mpd: local IP address for PPTP is 192.146.191.22 Jun 15 10:20:43 radio mpd: mpd: PPTP connection from 208.150.70.202:1032 Jun 15 10:20:43 radio mpd: pptp0: attached to connection with 208.150.70.202:1032 Jun 15 10:20:43 radio mpd: [pptp] IFACE: Open event Jun 15 10:20:43 radio mpd: [pptp] IPCP: Open event Jun 15 10:20:43 radio mpd: [pptp] IPCP: state change Initial --> Starting Jun 15 10:20:43 radio mpd: [pptp] IPCP: LayerStart Jun 15 10:20:43 radio mpd: [pptp] IPCP: Open event Jun 15 10:20:43 radio mpd: [pptp] bundle: OPEN event in state CLOSED Jun 15 10:20:43 radio mpd: [pptp] opening link "pptp"... Jun 15 10:20:43 radio mpd: [pptp] link: OPEN event Jun 15 10:20:43 radio mpd: [pptp] LCP: Open event Jun 15 10:20:43 radio mpd: [pptp] LCP: state change Initial --> Starting Jun 15 10:20:43 radio mpd: [pptp] LCP: LayerStart Jun 15 10:20:43 radio mpd: [pptp] device: OPEN event in state DOWN Jun 15 10:20:43 radio mpd: [pptp] attaching to peer's outgoing call Jun 15 10:20:43 radio mpd: [pptp] device is now in state OPENING Jun 15 10:20:43 radio mpd: [pptp] device: UP event in state OPENING Jun 15 10:20:43 radio mpd: [pptp] device is now in state UP Jun 15 10:20:43 radio mpd: [pptp] link: UP event Jun 15 10:20:43 radio mpd: [pptp] link: origination is remote Jun 15 10:20:43 radio mpd: [pptp] LCP: Up event Jun 15 10:20:43 radio mpd: [pptp] LCP: state change Starting --> Req-Sent Jun 15 10:20:43 radio mpd: [pptp] LCP: phase shift DEAD --> ESTABLISH Jun 15 10:20:43 radio mpd: [pptp] LCP: SendConfigReq #1 Jun 15 10:20:43 radio mpd: ACFCOMP Jun 15 10:20:43 radio mpd: PROTOCOMP Jun 15 10:20:43 radio mpd: MRU 1500 Jun 15 10:20:43 radio mpd: MAGICNUM 256f3566 Jun 15 10:20:43 radio mpd: AUTHPROTO CHAP MSOFT Jun 15 10:20:43 radio mpd: [pptp] LCP: rec'd Configure Request #1 link 0 (Req-Sent) Jun 15 10:20:43 radio mpd: ACCMAP 0x000a0000 Jun 15 10:20:43 radio mpd: MAGICNUM 00030b46 Jun 15 10:20:43 radio mpd: PROTOCOMP Jun 15 10:20:43 radio mpd: ACFCOMP Jun 15 10:20:43 radio mpd: CALLBACK Jun 15 10:20:43 radio mpd: Not supported Jun 15 10:20:43 radio mpd: [pptp] LCP: SendConfigRej #1 Jun 15 10:20:43 radio mpd: CALLBACK Jun 15 10:20:43 radio mpd: [pptp] error writing len 11 frame to bypass: No buffer space available Jun 15 10:20:45 radio mpd: [pptp] LCP: SendConfigReq #2 Jun 15 10:20:45 radio mpd: ACFCOMP Jun 15 10:20:45 radio mpd: PROTOCOMP Jun 15 10:20:45 radio mpd: MRU 1500 Jun 15 10:20:45 radio mpd: MAGICNUM 256f3566 Jun 15 10:20:45 radio mpd: AUTHPROTO CHAP MSOFT Jun 15 10:20:45 radio mpd: [pptp] error writing len 27 frame to bypass: No buffer space available Jun 15 10:20:47 radio mpd: [pptp] LCP: SendConfigReq #3 Jun 15 10:20:47 radio mpd: ACFCOMP Jun 15 10:20:47 radio mpd: PROTOCOMP Jun 15 10:20:47 radio mpd: MRU 1500 Jun 15 10:20:47 radio mpd: MAGICNUM 256f3566 Jun 15 10:20:47 radio mpd: AUTHPROTO CHAP MSOFT Jun 15 10:20:47 radio mpd: [pptp] error writing len 27 frame to bypass: No buffer space available Jun 15 10:20:47 radio mpd: [pptp] LCP: rec'd Configure Request #2 link 0 (Req-Sent) Jun 15 10:20:47 radio mpd: ACCMAP 0x000a0000 Jun 15 10:20:47 radio mpd: MAGICNUM 00030b46 Jun 15 10:20:47 radio mpd: PROTOCOMP Jun 15 10:20:47 radio mpd: ACFCOMP Jun 15 10:20:47 radio mpd: CALLBACK Jun 15 10:20:47 radio mpd: Not supported Jun 15 10:20:47 radio mpd: [pptp] LCP: SendConfigRej #2 Jun 15 10:20:47 radio mpd: CALLBACK Jun 15 10:20:47 radio mpd: [pptp] error writing len 11 frame to bypass: No buffer space available Jun 15 10:20:49 radio mpd: [pptp] LCP: SendConfigReq #4 Jun 15 10:20:49 radio mpd: ACFCOMP Jun 15 10:20:49 radio mpd: PROTOCOMP Jun 15 10:20:49 radio mpd: MRU 1500 Jun 15 10:20:49 radio mpd: MAGICNUM 256f3566 Jun 15 10:20:49 radio mpd: AUTHPROTO CHAP MSOFT Jun 15 10:20:49 radio mpd: [pptp] error writing len 27 frame to bypass: No buffer space available Jun 15 10:20:50 radio mpd: [pptp] LCP: rec'd Configure Request #3 link 0 (Req-Sent) Jun 15 10:20:50 radio mpd: ACCMAP 0x000a0000 Jun 15 10:20:50 radio mpd: MAGICNUM 00030b46 Jun 15 10:20:50 radio mpd: PROTOCOMP Jun 15 10:20:50 radio mpd: ACFCOMP Jun 15 10:20:50 radio mpd: CALLBACK Jun 15 10:20:50 radio mpd: Not supported Jun 15 10:20:50 radio mpd: [pptp] LCP: SendConfigRej #3 Jun 15 10:20:50 radio mpd: CALLBACK Jun 15 10:20:50 radio mpd: [pptp] error writing len 11 frame to bypass: No buffer space available Jun 15 10:20:51 radio mpd: [pptp] LCP: SendConfigReq #5 Jun 15 10:20:51 radio mpd: ACFCOMP Jun 15 10:20:51 radio mpd: PROTOCOMP Jun 15 10:20:51 radio mpd: MRU 1500 Jun 15 10:20:51 radio mpd: MAGICNUM 256f3566 Jun 15 10:20:51 radio mpd: AUTHPROTO CHAP MSOFT Jun 15 10:20:51 radio mpd: [pptp] error writing len 27 frame to bypass: No buffer space available Jun 15 10:20:53 radio mpd: [pptp] LCP: SendConfigReq #6 Jun 15 10:20:53 radio mpd: ACFCOMP Jun 15 10:20:53 radio mpd: PROTOCOMP Jun 15 10:20:53 radio mpd: MRU 1500 Jun 15 10:20:53 radio mpd: MAGICNUM 256f3566 Jun 15 10:20:53 radio mpd: AUTHPROTO CHAP MSOFT Jun 15 10:20:53 radio mpd: [pptp] LCP: rec'd Configure Request #4 link 0 (Req-Sent) Jun 15 10:20:53 radio mpd: ACCMAP 0x000a0000 Jun 15 10:20:53 radio mpd: MAGICNUM 00030b46 Jun 15 10:20:53 radio mpd: PROTOCOMP Jun 15 10:20:53 radio mpd: ACFCOMP Jun 15 10:20:53 radio mpd: CALLBACK Jun 15 10:20:53 radio mpd: Not supported Jun 15 10:20:53 radio mpd: [pptp] LCP: SendConfigRej #4 Jun 15 10:20:53 radio mpd: CALLBACK Jun 15 10:20:53 radio mpd: [pptp] LCP: rec'd Configure Ack #6 link 0 (Req-Sent) Jun 15 10:20:53 radio mpd: ACFCOMP Jun 15 10:20:53 radio mpd: PROTOCOMP Jun 15 10:20:53 radio mpd: MRU 1500 Jun 15 10:20:53 radio mpd: MAGICNUM 256f3566 Jun 15 10:20:53 radio mpd: AUTHPROTO CHAP MSOFT Jun 15 10:20:53 radio mpd: [pptp] LCP: state change Req-Sent --> Ack-Rcvd Jun 15 10:20:53 radio mpd: [pptp] LCP: rec'd Configure Request #5 link 0 (Ack-Rcvd) Jun 15 10:20:53 radio mpd: ACCMAP 0x000a0000 Jun 15 10:20:53 radio mpd: MAGICNUM 00030b46 Jun 15 10:20:53 radio mpd: PROTOCOMP Jun 15 10:20:53 radio mpd: ACFCOMP Jun 15 10:20:53 radio mpd: [pptp] LCP: SendConfigAck #5 Jun 15 10:20:53 radio mpd: ACCMAP 0x000a0000 Jun 15 10:20:53 radio mpd: MAGICNUM 00030b46 Jun 15 10:20:53 radio mpd: PROTOCOMP Jun 15 10:20:53 radio mpd: ACFCOMP Jun 15 10:20:53 radio mpd: [pptp] LCP: state change Ack-Rcvd --> Opened Jun 15 10:20:53 radio mpd: [pptp] LCP: phase shift ESTABLISH --> AUTHENTICATE Jun 15 10:20:53 radio mpd: [pptp] LCP: auth: peer wants nothing, I want CHAP Jun 15 10:20:53 radio mpd: [pptp] CHAP: sending CHALLENGE Jun 15 10:20:53 radio mpd: [pptp] LCP: LayerUp Jun 15 10:20:54 radio mpd: [pptp] CHAP: rec'd RESPONSE #1 Jun 15 10:20:54 radio mpd: Name: "steve" Jun 15 10:20:54 radio mpd: Peer name: "steve" Jun 15 10:20:54 radio mpd: Response is valid Jun 15 10:20:54 radio mpd: [pptp] CHAP: sending SUCCESS Jun 15 10:20:54 radio mpd: [pptp] LCP: authorization successful Jun 15 10:20:54 radio mpd: [pptp] LCP: phase shift AUTHENTICATE --> NETWORK Jun 15 10:20:54 radio mpd: [pptp] up: 1 link, total bandwidth 64000 bps Jun 15 10:20:54 radio mpd: [pptp] IPCP: Up event Jun 15 10:20:54 radio mpd: [pptp] IPCP: state change Starting --> Req-Sent Jun 15 10:20:54 radio mpd: [pptp] IPCP: SendConfigReq #1 Jun 15 10:20:54 radio mpd: IPADDR 10.0.0.1 Jun 15 10:20:54 radio mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jun 15 10:20:54 radio mpd: [pptp] CCP: Open event Jun 15 10:20:54 radio mpd: [pptp] CCP: state change Initial --> Starting Jun 15 10:20:54 radio mpd: [pptp] CCP: LayerStart Jun 15 10:20:54 radio mpd: [pptp] CCP: Up event Jun 15 10:20:54 radio mpd: [pptp] CCP: state change Starting --> Req-Sent Jun 15 10:20:54 radio mpd: [pptp] CCP: SendConfigReq #1 Jun 15 10:20:56 radio mpd: [pptp] IPCP: SendConfigReq #2 Jun 15 10:20:56 radio mpd: IPADDR 10.0.0.1 Jun 15 10:20:56 radio mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jun 15 10:20:56 radio mpd: [pptp] CCP: SendConfigReq #2 Jun 15 10:20:56 radio mpd: [pptp] error writing len 14 frame to bypass: No buffer space available Jun 15 10:20:58 radio mpd: [pptp] IPCP: SendConfigReq #3 Jun 15 10:20:58 radio mpd: IPADDR 10.0.0.1 Jun 15 10:20:58 radio mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jun 15 10:20:58 radio mpd: [pptp] CCP: SendConfigReq #3 Jun 15 10:20:59 radio mpd: [pptp] CHAP: rec'd RESPONSE #1 Jun 15 10:20:59 radio mpd: Not expected, but that's OK Jun 15 10:20:59 radio mpd: Name: "steve" Jun 15 10:20:59 radio mpd: Peer name: "steve" Jun 15 10:20:59 radio mpd: Response is valid Jun 15 10:20:59 radio mpd: [pptp] CHAP: sending SUCCESS Jun 15 10:20:59 radio mpd: [pptp] LCP: authorization successful Jun 15 10:20:59 radio mpd: [pptp] IPCP: rec'd Configure Request #1 link 0 (Req-Sent) Jun 15 10:20:59 radio mpd: COMPPROTO VJCOMP, 16 comp. channels, allow comp-cid Jun 15 10:20:59 radio mpd: IPADDR 0.0.0.0 Jun 15 10:20:59 radio mpd: NAKing with 10.0.0.2 Jun 15 10:20:59 radio mpd: PRIDNS 0.0.0.0 Jun 15 10:20:59 radio mpd: NAKing with 192.146.191.13 Jun 15 10:20:59 radio mpd: PRINBNS 0.0.0.0 Jun 15 10:20:59 radio mpd: SECDNS 0.0.0.0 Jun 15 10:20:59 radio mpd: SECNBNS 0.0.0.0 Jun 15 10:20:59 radio mpd: [pptp] IPCP: SendConfigRej #1 Jun 15 10:20:59 radio mpd: PRINBNS 0.0.0.0 Jun 15 10:20:59 radio mpd: SECDNS 0.0.0.0 Jun 15 10:20:59 radio mpd: SECNBNS 0.0.0.0 Jun 15 10:20:59 radio mpd: [pptp] CCP: rec'd Configure Request #1 link 0 (Req-Sent) Jun 15 10:20:59 radio mpd: [pptp] CCP: SendConfigNak #1 Jun 15 10:21:00 radio mpd: [pptp] IPCP: SendConfigReq #4 Jun 15 10:21:00 radio mpd: IPADDR 10.0.0.1 Jun 15 10:21:00 radio mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jun 15 10:21:00 radio mpd: [pptp] CCP: SendConfigReq #4 Jun 15 10:21:00 radio mpd: [pptp] error writing len 14 frame to bypass: No buffer space available Jun 15 10:21:00 radio mpd: [pptp] IPCP: rec'd Configure Ack #4 link 0 (Req-Sent) Jun 15 10:21:00 radio mpd: IPADDR 10.0.0.1 Jun 15 10:21:00 radio mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jun 15 10:21:00 radio mpd: [pptp] IPCP: state change Req-Sent --> Ack-Rcvd Jun 15 10:21:02 radio mpd: [pptp] CCP: SendConfigReq #5 Jun 15 10:21:02 radio mpd: [pptp] CCP: rec'd Configure Nak #5 link 0 (Req-Sent) Jun 15 10:21:02 radio mpd: [pptp] CCP: SendConfigReq #6 Jun 15 10:21:02 radio mpd: [pptp] CCP: rec'd Configure Ack #6 link 0 (Req-Sent) Jun 15 10:21:02 radio mpd: [pptp] CCP: state change Req-Sent --> Ack-Rcvd Jun 15 10:21:02 radio mpd: [pptp] CCP: rec'd Configure Request #2 link 0 (Ack-Rcvd) Jun 15 10:21:02 radio mpd: [pptp] CCP: SendConfigNak #2 Jun 15 10:21:02 radio mpd: [pptp] IPCP: rec'd Configure Request #2 link 0 (Ack-Rcvd) Jun 15 10:21:02 radio mpd: COMPPROTO VJCOMP, 16 comp. channels, allow comp-cid Jun 15 10:21:02 radio mpd: IPADDR 0.0.0.0 Jun 15 10:21:02 radio mpd: NAKing with 10.0.0.2 Jun 15 10:21:02 radio mpd: PRIDNS 0.0.0.0 Jun 15 10:21:02 radio mpd: NAKing with 192.146.191.13 Jun 15 10:21:02 radio mpd: PRINBNS 0.0.0.0 Jun 15 10:21:02 radio mpd: SECDNS 0.0.0.0 Jun 15 10:21:02 radio mpd: SECNBNS 0.0.0.0 Jun 15 10:21:02 radio mpd: [pptp] IPCP: SendConfigRej #2 Jun 15 10:21:02 radio mpd: PRINBNS 0.0.0.0 Jun 15 10:21:02 radio mpd: SECDNS 0.0.0.0 Jun 15 10:21:02 radio mpd: SECNBNS 0.0.0.0 Jun 15 10:21:02 radio mpd: [pptp] CCP: rec'd Configure Request #3 link 0 (Ack-Rcvd) Jun 15 10:21:02 radio mpd: [pptp] CCP: SendConfigAck #3 Jun 15 10:21:02 radio mpd: [pptp] CCP: state change Ack-Rcvd --> Opened Jun 15 10:21:02 radio mpd: [pptp] CCP: LayerUp Jun 15 10:21:02 radio mpd: [pptp] can't create mppc node: Device not configured Jun 15 10:21:02 radio mpd: [pptp] CCP: parameter negotiation failed Jun 15 10:21:02 radio mpd: [pptp] CCP: Close event Jun 15 10:21:02 radio mpd: [pptp] CCP: state change Opened --> Closing Jun 15 10:21:02 radio mpd: [pptp] CCP: SendTerminateReq #7 Jun 15 10:21:02 radio mpd: [pptp] CCP: LayerDown Jun 15 10:21:02 radio mpd: [pptp] CCP: state change Closing --> Closed Jun 15 10:21:02 radio mpd: [pptp] CCP: LayerFinish Jun 15 10:21:02 radio mpd: [pptp] IPCP: rec'd Configure Request #3 link 0 (Ack-Rcvd) Jun 15 10:21:02 radio mpd: COMPPROTO VJCOMP, 16 comp. channels, allow comp-cid Jun 15 10:21:02 radio mpd: IPADDR 0.0.0.0 Jun 15 10:21:02 radio mpd: NAKing with 10.0.0.2 Jun 15 10:21:02 radio mpd: PRIDNS 0.0.0.0 Jun 15 10:21:02 radio mpd: NAKing with 192.146.191.13 Jun 15 10:21:02 radio mpd: [pptp] IPCP: SendConfigNak #3 Jun 15 10:21:02 radio mpd: IPADDR 10.0.0.2 Jun 15 10:21:02 radio mpd: PRIDNS 192.146.191.13 Jun 15 10:21:05 radio mpd: [pptp] IPCP: rec'd Configure Request #4 link 0 (Ack-Rcvd) Jun 15 10:21:05 radio mpd: COMPPROTO VJCOMP, 16 comp. channels, allow comp-cid Jun 15 10:21:05 radio mpd: IPADDR 0.0.0.0 Jun 15 10:21:05 radio mpd: NAKing with 10.0.0.2 Jun 15 10:21:05 radio mpd: PRIDNS 0.0.0.0 Jun 15 10:21:05 radio mpd: NAKing with 192.146.191.13 Jun 15 10:21:05 radio mpd: [pptp] IPCP: SendConfigNak #4 Jun 15 10:21:05 radio mpd: IPADDR 10.0.0.2 Jun 15 10:21:05 radio mpd: PRIDNS 192.146.191.13 Jun 15 10:21:06 radio mpd: [pptp] IPCP: rec'd Configure Request #5 link 0 (Ack-Rcvd) Jun 15 10:21:06 radio mpd: COMPPROTO VJCOMP, 16 comp. channels, allow comp-cid Jun 15 10:21:06 radio mpd: IPADDR 10.0.0.2 Jun 15 10:21:06 radio mpd: 10.0.0.2 is OK Jun 15 10:21:06 radio mpd: PRIDNS 192.146.191.13 Jun 15 10:21:06 radio mpd: [pptp] IPCP: SendConfigAck #5 Jun 15 10:21:06 radio mpd: COMPPROTO VJCOMP, 16 comp. channels, allow comp-cid Jun 15 10:21:06 radio mpd: IPADDR 10.0.0.2 Jun 15 10:21:06 radio mpd: PRIDNS 192.146.191.13 Jun 15 10:21:06 radio mpd: [pptp] IPCP: state change Ack-Rcvd --> Opened Jun 15 10:21:06 radio mpd: [pptp] IPCP: LayerUp Jun 15 10:21:06 radio mpd: 10.0.0.1 -> 10.0.0.2 Jun 15 10:21:06 radio mpd: [pptp] IFACE: Up event Jun 15 10:21:06 radio mpd: [pptp] exec: /sbin/ifconfig ng0 10.0.0.1 10.0.0.2 netmask 0xffffffff -link0 Jun 15 10:21:06 radio mpd: [pptp] exec: /usr/sbin/arp -s 10.0.0.2 48:54:e8:28:e7:a1 pub Jun 15 10:21:07 radio mpd: [pptp] rec'd unexpected protocol COMPD on link 0 Jun 15 10:21:38 radio last message repeated 16 times Jun 15 10:21:41 radio last message repeated 2 times Jun 15 10:21:51 radio mpd: mpd: caught fatal signal int Jun 15 10:21:51 radio mpd: mpd: fatal error, exiting Jun 15 10:21:51 radio mpd: [pptp] IPCP: Down event Jun 15 10:21:51 radio mpd: [pptp] IPCP: state change Opened --> Starting Jun 15 10:21:51 radio mpd: [pptp] IPCP: LayerDown Jun 15 10:21:51 radio mpd: [pptp] IFACE: Down event Jun 15 10:21:51 radio mpd: [pptp] exec: /usr/sbin/arp -d 10.0.0.2 Jun 15 10:21:51 radio mpd: [pptp] exec: /sbin/ifconfig ng0 down delete -link0 Jun 15 10:21:51 radio mpd: [pptp] IFACE: Close event Jun 15 10:21:51 radio mpd: [pptp] IPCP: Close event Jun 15 10:21:51 radio mpd: [pptp] IPCP: state change Starting --> Initial Jun 15 10:21:51 radio mpd: [pptp] IPCP: LayerFinish Jun 15 10:21:51 radio mpd: mpd: process 29701 terminated show link gives: [pptp:pptp] show link Link pptp: Configuration MRU : 1500 bytes Ctrl char map : 0x000a0000 bytes Retry timeout : 2 seconds Max redial : 0 connect attempts Bandwidth : 64000 bits/sec Latency : 2000 usec Keep-alive : every 10 secs, timeout 60 Ident string : "" Link level options Name Self Peer ---------------------------------------- pap disable deny chap enable deny acfcomp enable accept protocomp enable accept magicnum enable passive disable check-magic enable no-orig-auth disable callback disable Traffic stats: Octets input : 1747 Frames input : 33 Octets output : 270 Frames output : 16 Bad protocols : 0 Runts : 0 Dup fragments : 0 Drop fragments : 0 Device specific info: Type : pptp State : UP PPTP status: Connection : UP Peer range : 0.0.0.0/0 Current peer : 208.150.70.202, port 1034 PPTP options: Name Self Peer ---------------------------------------- originate disable incoming enable outcall enable shop cpp gives: [pptp:pptp] show ccp [pptp] CCP [Closed] Enabled protocols: Name Self Peer ---------------------------------------- mppc enable accept mpp-compress disable deny mpp-e40 enable accept mpp-e128 enable accept mpp-stateless enable accept Incoming decompression: Protocol: MPPE, 40 bit, stateless Outgoing compression: Protocol: MPPE, 40 bit, stateless show lcp gives: [pptp:pptp] show lcp LCP [Opened] Self: MRU : 1500 bytes MAGIC : 0x752205a2 ACCMAP : 0x000a0000 ACFCOMP : Yes PROTOCOMP: Yes Peer: MRU : 1500 bytes MAGIC : 0x000e494f ACCMAP : 0x000a0000 ACFCOMP : Yes PROTOCOMP: Yes ifconfig: ed0: flags=8843 mtu 1500 inet 192.146.191.22 netmask 0xffffff00 broadcast 192.146.191.255 inet6 fe80::4a54:e8ff:fe28:e7a1%ed0 prefixlen 64 scopeid 0x1 inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 ether 48:54:e8:28:e7:a1 lp0: flags=8810 mtu 1500 sl0: flags=c010 mtu 552 ppp0: flags=8010 mtu 1500 lo0: flags=8049 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 gif0: flags=8010 mtu 1280 inet6 fe80::4a54:e8ff:fe28:e7a1%gif0 prefixlen 64 scopeid 0x6 gif1: flags=8010 mtu 1280 inet6 fe80::4a54:e8ff:fe28:e7a1%gif1 prefixlen 64 scopeid 0x7 gif2: flags=8010 mtu 1280 inet6 fe80::4a54:e8ff:fe28:e7a1%gif2 prefixlen 64 scopeid 0x8 gif3: flags=8010 mtu 1280 inet6 fe80::4a54:e8ff:fe28:e7a1%gif3 prefixlen 64 scopeid 0x9 stf0: flags=8000 mtu 1280 inet6 fe80::4a54:e8ff:fe28:e7a1%stf0 prefixlen 64 scopeid 0xa faith0: flags=8000 mtu 1500 ng0: flags=88d1 mtu 1498 inet 10.0.0.1 --> 10.0.0.2 netmask 0xffffffff netstat -nr: radio> netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.146.191.2 UGSc 11 573 ed0 10/24 link#1 UC 0 0 ed0 => 10.0.0.2 10.0.0.1 UH 0 0 ng0 10.0.0.2 48:54:e8:28:e7:a1 UHLS2 0 0 ed0 127.0.0.1 127.0.0.1 UH 0 159 lo0 192.146.191 link#1 UC 0 0 ed0 => 192.146.191.2 0:30:19:71:2c:1 UHLW 11 0 ed0 1195 192.146.191.13 0:90:27:5a:fd:66 UHLW 0 24 ed0 1158 192.146.191.22 48:54:e8:28:e7:a1 UHLW 0 248 lo0 tcpdump on remote while pinging from local: radio# tcpdump host 10.0.0.2 tcpdump: listening on ed0 ^C 317 packets received by filter 0 packets dropped by kernel radio# tcpdump host 10.0.0.1 tcpdump: listening on ed0 ^C 386 packets received by filter 0 packets dropped by kernel nothing... but when I ping in either direction... I get: [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 [pptp] rec'd unexpected protocol COMPD on link 0 this did not happen when it was working? Is this a 'stable' problem? Or am I doing something else stupid? Thanks for any help! -steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 16 12:52: 7 2000 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 6435537BA20 for ; Fri, 16 Jun 2000 12:52:03 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id PAA18933; Fri, 16 Jun 2000 15:51:59 -0400 (EDT) (envelope-from wollman) Date: Fri, 16 Jun 2000 15:51:59 -0400 (EDT) From: Garrett Wollman Message-Id: <200006161951.PAA18933@khavrinen.lcs.mit.edu> To: "Daniel C. Sobral" Cc: net@freebsd.org Subject: Re: cvs commit: src/sys/kern uipc_socket.c uipc_socket2.c src/sys/syssocket.h In-Reply-To: <394A838A.F3417365@newsguy.com> References: <394A838A.F3417365@newsguy.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Discussion redirected.] < said: [Wow, what timezone is that?] > After seeing the code, I can't see why can't userland provide the > strings to be matched. I would be willing to tolerate a hack which allowed users to specify a specific *character* to wait for (which in most line-based Internet protocols would be '\n'). -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 16 13: 1:58 2000 Delivered-To: freebsd-net@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 35F9737C006 for ; Fri, 16 Jun 2000 13:01:52 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p10-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.11]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id FAA16500; Sat, 17 Jun 2000 05:01:47 +0900 (JST) Message-ID: <394A87E5.2DC2CF05@newsguy.com> Date: Sat, 17 Jun 2000 05:02:45 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Garrett Wollman Cc: net@freebsd.org Subject: Re: cvs commit: src/sys/kern uipc_socket.c uipc_socket2.c src/sys/syssocket.h References: <394A838A.F3417365@newsguy.com> <200006161951.PAA18933@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Garrett Wollman wrote: > > [Discussion redirected.] > > < said: > > [Wow, what timezone is that?] .jp > > After seeing the code, I can't see why can't userland provide the > > strings to be matched. > > I would be willing to tolerate a hack which allowed users to specify a > specific *character* to wait for (which in most line-based Internet > protocols would be '\n'). Alas, I'm thinking... What happens if you never get a valid match? Have we just introduced a new way to DoS ourselves? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.great.underground.bsdconpiracy.org "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 16 13:20:12 2000 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 3AAB937B696 for ; Fri, 16 Jun 2000 13:20:10 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id QAA19013; Fri, 16 Jun 2000 16:20:08 -0400 (EDT) (envelope-from wollman) Date: Fri, 16 Jun 2000 16:20:08 -0400 (EDT) From: Garrett Wollman Message-Id: <200006162020.QAA19013@khavrinen.lcs.mit.edu> To: "Daniel C. Sobral" Cc: net@freebsd.org Subject: Re: cvs commit: src/sys/kern uipc_socket.c uipc_socket2.c src/sys/syssocket.h In-Reply-To: <394A87E5.2DC2CF05@newsguy.com> References: <394A838A.F3417365@newsguy.com> <200006161951.PAA18933@khavrinen.lcs.mit.edu> <394A87E5.2DC2CF05@newsguy.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Alas, I'm thinking... What happens if you never get a valid match? Have > we just introduced a new way to DoS ourselves? No, you just start a timeout when the connection is completed that will force the accept to completion after a few seconds of waiting, or the state of the connection changes, or there's more than a certain amount (SB_LOWAT) of data in the buffer. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 16 20:26:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 4691537B87F; Fri, 16 Jun 2000 20:25:46 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id VAA57866; Fri, 16 Jun 2000 21:25:45 -0600 (MDT) (envelope-from ken) Date: Fri, 16 Jun 2000 21:25:45 -0600 From: "Kenneth D. Merry" To: net@FreeBSD.ORG Subject: zero copy sockets and NFS code for FreeBSD Message-ID: <20000616212545.A57840@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ This message is BCC'ed to -arch and -current, so it reaches a little wider audience, but since it mostly deals with networking stuff, it should probably be discussed on -net. ] Thanks to the efforts of a number of people, zero copy sockets and NFS patches are available for FreeBSD-current at the URL listed below. These patches include: - Two sets of zero copy send code, written by Drew Gallatin and Robert Picco . - Zero copy receive code, written by Drew Gallatin. - Zero copy NFS code, written by Drew Gallatin. - Header splitting firmware for Alteon's Tigon II boards (written by me), based on version 12.4.11 of their firmware. This is used in combination with the zero copy receive code to guarantee that the payload of TCP or UDP packet is placed into a page-aligned buffer. - Alteon firmware debugging ioctls and supporting routines for the Tigon driver (also written by me). This will help anyone who is doing firmware development under FreeBSD for the Tigon boards. Please note that the code is still in development, and should not be used in a production system. It could crash your system, you could lose data, etc. The Alteon firmware header splitting and debugging code was written for Pluto Technologies (www.plutotech.com), which has kindly agreed to let me release the code. I'm releasing these patches now, so people can take a look at the code, test it out, give feedback and hopefully supply patches for things that are broken. The code is located here: http://people.FreeBSD.ORG/~ken/zero_copy/ The patches are based on -current from early in the day on June 13th, i.e. before Peter's config changes. Frequently Asked Questions: 1. Known Problems. 2. What is "zero copy"? 3. How does zero copy work? 4. What hardware does it work with? 5. Configuration and performance tuning. 6. Benchmarks. 7. Possible future directions. 1. Known Problems: - Robert Picco's zero copy send code (options ZCOPY) corrupts data that it sends. You can verify this with the 'nttcp' port from ports/net, like this: nttcp -c -n 262144 -t -T -w 512k 10.0.0.2 (assuming 10.0.0.2 is the target machine) - Running high volumes of traffic to the local machine can trigger panics. If the machine in question is '10.0.0.2', doing the following is enough to panic it: netperf -H 10.0.0.2 (netperf is in ports/benchmarks) 2. What is "zero copy"? Zero copy is a misnomer, or an accurate description, depending on how you look at things. In the normal case, with network I/O, buffers are copied from the user process into the kernel on the send side, and from the kernel into the user process on the receiving side. That is the copy that is being eliminated in this case. The DMA or copy from the kernel into the NIC, or from the NIC into the kernel is not the copy that is being eliminated. In fact you can't eliminate that copy without taking packet processing out of the kernel altogether. (i.e. the kernel has to see the packet headers in order to determine what to do with the payload) Memory copies from userland into the kernel are one of the largest bottlenecks in network performance on a BSD system, so eliminating them can greatly increase network throughput, and decrease system load when CPU or memory bandwidth isn't the limiting factor. 3. How does zero copy work? The send side and receive side zero copy code work in different ways: The send side code takes pages that the userland program writes to a socket, and puts a COW (Copy On Write) mapping on each page, and stuffs it into a mbuf. The data the user program writes must be page sized and start on a page boundary in order for it to be run through the zero copy send code. If the userland program doesn't write to the page before it has been sent out on the wire and the mbuf freed (and therefore the COW mapping revoked), the page will be copied. For TCP, the mbuf isn't freed until the packet is acknowledged by the receiver. So send side zero copy is only better than the standard case, where userland buffers are copied into kernel buffers, if the userland program doesn't immediately reuse the buffer. Receive side zero copy works in a slightly different manner, and depends in part on the capabilities of the network card in question. One requirement for zero copy receive to work is that the chunks of data passed up the network and socket layers have to be at least page sized, and be aligned on page boundaries. This pretty much means that the card has to have a MTU of 4K or 8K in the case of the Alpha. Gigabit Ethernet cards using Jumbo Frames (9000 byte MTU) fall into this category. More on that below. Another requirement for zero copy receive to work is that the NIC driver needs to allocate receive side pages from a "disposeable" pool. This means allocating memory apart from the normal mbuf memory, and attaching it as an external buffer to the mbuf. It also helps if the NIC can receive packets into multiple buffers, and if the NIC can separate the ethernet, IP, and TCP or UDP headers from the payload. The idea is to get the packet payload into one or more page-sized, page-aligned buffers. The NIC driver receives data into these buffers allocated from a disposeable pool. The mbuf with these buffers attached is then passed up the network stack where the headers are removed. Finally it reaches the socket layer, and waits for the user to read it. Once the user reads the data, the kernel page is then substituted for the user's page, and the user's page is then recycled. This is otherwise known as "page flipping". The page flip can only occur if both the userland buffer and kernel buffer are page aligned, and if there is at least a page worth of data in the source and destination. Otherwise the data will be copied out using copyout() in the normal manner. 4. What hardware does it work with? The send side zero copy code should work with most any network adapter. The receive side code, however, requires an adapter with an MTU that is at least a page size, due to the alignment restrictions for page substitution (or "page flipping"). The zero-copy NFS receive-side code also requires an adapter with an MTU that is at least page-size & which is capable of splitting the NFS rpc header off of the payload. Furthermore, it only works with UDP mounts. The server's zero-copy read response code simply maps kernel memory into mbufs and has no special adapter or protocol requirements. The Alteon firmware debugging code requires an Alteon Tigon II board. If you want the patches to the userland tools and Tigon firmware to debug it and make it compile under FreeBSD, contact ken@FreeBSD.ORG. 5. Configuration and performance tuning. There are a number of options that need to be turned on for various things to work: options ZERO_COPY_SOCKETS # Turn on zero copy send code options ENABLE_VFS_IOOPT # Turn on zero copy receive options NMBCLUSTERS=(512+512*32) # lots of mbuf clusters options TI_JUMBO_HDRSPLIT # Turn on Tigon header splitting To turn on Robert Picco's zero copy send code, substitute: options ZCOPY # Robert Picco's zero copy code for the ZERO_COPY_SOCKETS option above. The number of mbuf clusters above works for me, your mileage may vary. It probably isn't necessary to allocate that many. To get the maximum performance out of the code, here are some suggestions on various sysctl and other parameters. These assume you've got an Alteon-based board, so if you're using something else, you may want to experiment and find the optimum values for some of them: - Make sure the MTU on your Tigon (or other) board is set to 9000. - Enable RFC 1323, which allows your TCP MSS to go above 64KB: sysctl -w net.inet.tcp.rfc1323=1 - Turn on vfs.ioopt to enable zero copy receive: sysctl -w vfs.ioopt=1 - Increase your socket buffer size and send and receive window size for TCP: sysctl -w kern.ipc.maxsockbuf=2097152 sysctl -w net.inet.tcp.sendspace=524288 sysctl -w net.inet.tcp.recvspace=524288 A send window of 512K seems to work well with 1MB Tigon boards, and a send window of 256K seems to work well with 512K Tigon boards. Again, you may want to experiment to find the best settings for your hardware. - Increase UDP send space and maximum datagram size: sysctl -w net.inet.udp.recvspace=65535 sysctl -w net.inet.udp.maxdgram=57344 6. Benchmarks One nice benchmark is netperf (www.netperf.org), which is in the benchmarks subdirectory of the ports tree. Netperf isn't exactly a real world benchmark, since it sends page aligned data that is a multiple of the page size. It is good for trying to determine maximum throughput. Another benchmark to try is nttcp, which is in ports/net. Here is are some netperf numbers for TCP and UDP throughput between two Pentium II 350's with 128MB RAM and 1MB Alteon ACEnics: # ./netperf -H 10.0.0.1 TCP STREAM TEST to 10.0.0.1 : histogram Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 524288 524288 524288 10.01 742.46 # ./netperf -t UDP_STREAM -H 10.0.0.1 -- -m 8192 UDP UNIDIRECTIONAL SEND TEST to 10.0.0.1 : histogram Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 57344 8192 10.01 140396 585086 919.34 65535 10.01 93525 612.42 As you can see, the TCP performance is 742Mbits/sec, or about 93MBytes/sec. Drew Gallatin has achieved much higher performance with faster hardware: This is between 2 Dell PowerEdge 4400 servers using prototype 64-bit, 66MHz PCI Myricom Lanai-9 NICs with a 2.56Gb/sec link speed. The MTU was 32828 bytes. They're both uniprocessor 733MHz Xeons running a heavily patched 4.0-RELEASE & my zero-copy code in conjunction with Duke's Trapeze software (drive & firmware) for Myrinet adapters. The receiver is offloading checksums and is 60% idle, the sender is calculating checksums and is pegged at 100% CPU. <9:12am>wrath/gallatin:~>netperf -Hsloth-my TCP STREAM TEST to sloth-my : histogram Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 524288 524288 524288 10.00 1764.50 7. Possible future directions. Send side zero copy: One of the obvious problems with the current send side approach is that it only works if the userland application doesn't immediately reuse the buffer. In the case of many system applications, though, the application will reuse the buffer immediately, and therefore performance will be no better than the standard case. Many common applications (like ftp) have been written with the current system buffer usage in mind, so they function like this: while !done { read x bytes from disk into buffer y write x bytes from buffer y into the socket } That makes sense if the kernel is only going to copy the data, but it doesn't in the zero copy case. Another problem with the current send side approach is that it requires page sized and page aligned data in order to apply the COW mapping. Not all data sets fit this requirement. One way to address both of the above problems is to implement an alternate zero copy send scheme that uses async I/O. With async I/O semantics, it will be clear to the userland program that the buffer in question is not to be used until it is returned from the kernel. So with that approach, you eliminate the need to map the data copy-on-write, and therefore also eliminate the need for the data to be page sized and page aligned. Receive side zero copy: The main issue with the current receive side zero copy code is the size and alignment restrictions. One way to get around the restriction is if it were possible to do operations similar to a page flip on buffers that are less than a page size. Another way to get around the restriction is to have the receiving client pass buffers into the kernel (perhaps with an async I/O type interface) and have the NIC DMA the data directly into the buffers the user has supplied. One proposal for doing this is called RDMA. There is a draft of the specification here: ftp://ftpeng.cisco.com/pub/rdma/draft-csapuntz-tcprdma-00.txt Essentially RDMA allows for the sender and receiver to negotiate destination buffer locations on the receiver. The sender then includes the buffer locations in a TCP header option, and the NIC can then extract the destination location for the payload and DMA it to the appropriate place. One drawback to this approach is that it requires support for RDMA on both ends of the connection. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 17 3:14:13 2000 Delivered-To: freebsd-net@freebsd.org Received: from totem.fix.no (totem.fix.no [213.142.66.130]) by hub.freebsd.org (Postfix) with ESMTP id BE70637B6EE for ; Sat, 17 Jun 2000 03:14:01 -0700 (PDT) (envelope-from anders@totem.fix.no) Received: by totem.fix.no (Postfix, from userid 1000) id E495F572B; Sat, 17 Jun 2000 12:16:48 +0200 (CEST) Date: Sat, 17 Jun 2000 12:16:48 +0200 From: Anders Nordby To: freebsd-net@freebsd.org Subject: Dummynet instability Message-ID: <20000617121648.A9857@totem.fix.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i X-Operating-System: FreeBSD 3.4-STABLE X-Warning: Listen, and thou shall not fear. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I've been using Dummynet for quite some time with no stability problems. Just recently, I added some more ipfw rules sending traffic to my 3 pipes, which makes them: 08100 pipe 3 tcp from any to n.n.n.n 80 via ed1 08101 pipe 3 tcp from n.n.n.n 80 to any via ed1 08102 pipe 3 tcp from any to n.n.n.n 21,20 via ed1 08103 pipe 3 tcp from n.n.n.n 21,20 to any via ed1 08104 pipe 1 udp from any to any via ed1 08105 pipe 1 tcp from any to any via ed1 08106 pipe 1 ip from any to any via ed1 08200 pipe 2 icmp from any to any via ed1 (Where n.n.n.n is my IP.) I've been getting some "/kernel: -- warning, refcnt now 0, decreasing" and "/kernel: -- warning, refcnt now -1, decreasing" text in my messages log lately, and experienced two unexpected reboots (one of them was just after these messages). It seems this was mentioned on this list in november last year. I'm running FreeBSD 3.4-STABLE as of Wednesday the 19th of January. Has this been fixed? Any tips on how to improve the situation? Regards, -- Anders. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 17 9: 3: 2 2000 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 762F437B528 for ; Sat, 17 Jun 2000 09:02:58 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id SAA02716; Sat, 17 Jun 2000 18:04:27 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200006171604.SAA02716@info.iet.unipi.it> Subject: Re: Dummynet instability In-Reply-To: <20000617121648.A9857@totem.fix.no> from Anders Nordby at "Jun 17, 2000 12:16:48 pm" To: Anders Nordby Date: Sat, 17 Jun 2000 18:04:27 +0200 (CEST) Cc: freebsd-net@FreeBSD.ORG 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 X-Loop: FreeBSD.org > Hi, > > I've been using Dummynet for quite some time with no stability > problems. Just recently, I added some more ipfw rules sending traffic to > my 3 pipes, which makes them: ... > I've been getting some "/kernel: -- warning, refcnt now 0, decreasing" and > "/kernel: -- warning, refcnt now -1, decreasing" text in my messages log ... > Has this been fixed? Any tips on how to improve the situation? am looking at the cvs logs to understand what was going on, but at first sight the code seems the same (functionally speaking) that fixed the problem in november. anyways, this problem was related with route entries changing/going away while the packet is stored in the dummynet (which does not last long, usually a few seconds). So, what is your underlying network structure, do you have multiple interfaces or routes that change etc ? cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 17 9:31:12 2000 Delivered-To: freebsd-net@freebsd.org Received: from totem.fix.no (totem.fix.no [213.142.66.130]) by hub.freebsd.org (Postfix) with ESMTP id 31D9237B5CE for ; Sat, 17 Jun 2000 09:31:10 -0700 (PDT) (envelope-from anders@totem.fix.no) Received: by totem.fix.no (Postfix, from userid 1000) id 3C72A572B; Sat, 17 Jun 2000 18:34:01 +0200 (CEST) Date: Sat, 17 Jun 2000 18:34:01 +0200 From: Anders Nordby To: Luigi Rizzo Cc: freebsd-net@FreeBSD.ORG Subject: Re: Dummynet instability Message-ID: <20000617183401.A16130@totem.fix.no> References: <20000617121648.A9857@totem.fix.no> <200006171604.SAA02716@info.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200006171604.SAA02716@info.iet.unipi.it>; from luigi@info.iet.unipi.it on Sat, Jun 17, 2000 at 06:04:27PM +0200 X-Operating-System: FreeBSD 3.4-STABLE X-Warning: Listen, and thou shall not fear. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Jun 17, 2000 at 06:04:27PM +0200, Luigi Rizzo wrote: > am looking at the cvs logs to understand what was going on, > but at first sight the code seems the same (functionally speaking) > that fixed the problem in november. > > anyways, this problem was related with route entries changing/going > away while the packet is stored in the dummynet (which does not > last long, usually a few seconds). So, what is your underlying network > structure, do you have multiple interfaces or routes that change etc ? It's a one NIC machine, only having a route for it's own subnet, and a default route to a gateway there. Plus for loopback. In the kernel I have the following network options in addition to GENERIC: options IPFIREWALL options DUMMYNET options BRIDGE options "ICMP_BANDLIM" options IPDIVERT options IPFIREWALL_FORWARD (I don't need BRIDGE and IPDIVERT though.) -- Anders. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 17 9:34:12 2000 Delivered-To: freebsd-net@freebsd.org Received: from paprika.michvhf.com (paprika.michvhf.com [209.103.136.12]) by hub.freebsd.org (Postfix) with SMTP id 81A4337B5BA for ; Sat, 17 Jun 2000 09:34:08 -0700 (PDT) (envelope-from vev@michvhf.com) Received: (qmail 23760 invoked by uid 1001); 17 Jun 2000 16:34:11 -0000 Date: Sat, 17 Jun 2000 12:34:11 -0400 (EDT) From: Vince Vielhaber To: Anders Nordby Cc: Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: Dummynet instability In-Reply-To: <20000617183401.A16130@totem.fix.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 17 Jun 2000, Anders Nordby wrote: > On Sat, Jun 17, 2000 at 06:04:27PM +0200, Luigi Rizzo wrote: > > am looking at the cvs logs to understand what was going on, > > but at first sight the code seems the same (functionally speaking) > > that fixed the problem in november. > > > > anyways, this problem was related with route entries changing/going > > away while the packet is stored in the dummynet (which does not > > last long, usually a few seconds). So, what is your underlying network > > structure, do you have multiple interfaces or routes that change etc ? > > It's a one NIC machine, only having a route for it's own subnet, and a > default route to a gateway there. Plus for loopback. In the kernel I have > the following network options in addition to GENERIC: > > options IPFIREWALL > options DUMMYNET > options BRIDGE > options "ICMP_BANDLIM" > options IPDIVERT > options IPFIREWALL_FORWARD > > (I don't need BRIDGE and IPDIVERT though.) > > Could something like portsentry be doing it? IIRC if told it will reroute if someone hits one of the listed ports. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ========================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 17 11: 5:45 2000 Delivered-To: freebsd-net@freebsd.org Received: from modemcable127.61-201-24.mtl.mc.videotron.net (modemcable127.61-201-24.mtl.mc.videotron.net [24.201.61.127]) by hub.freebsd.org (Postfix) with SMTP id 25A6C37B5E7 for ; Sat, 17 Jun 2000 11:05:42 -0700 (PDT) (envelope-from patrick@mindstep.com) Received: (qmail 1409 invoked from network); 17 Jun 2000 18:05:40 -0000 Received: from patrak.local.mindstep.com (HELO PATRAK) (192.168.10.4) by jacuzzi.local.mindstep.com with SMTP; 17 Jun 2000 18:05:40 -0000 Message-ID: <010101bfd886$a4e23a50$040aa8c0@local.mindstep.com> From: "Patrick Bihan-Faou" To: "Josef Karthauser" , Cc: References: <200006162014.NAA12344@freefall.freebsd.org> <20000617011757.C4271@pavilion.net> Subject: Re: cvs commit: src/sys/sys sockio.h src/sys/net if.c src/sbin/ifconfig ifconfig.8 ifconfig.c Date: Sat, 17 Jun 2000 14:05:39 -0400 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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, ----- Original Message ----- From: "Josef Karthauser" > Horray! At last there's some hope of getting dhcp to give me the same > lease irrespective of which pccard ethernet card I plug in :). You can already to this by specifying the DHCP client-id for your machine. Most DHCP servers will honor that and since it is under your control, you don't need to hack the MAC address to obtain the same lease even when you change you ethernet card. I also implemented a patch for ISC-DHCP v2 to use the value passed in the client-id field or the hostname field of0 the DHCP request/discover to fetch the appropriate IP address from a DNS server. This reduces the number of things to configure for a LAN. Changing the MAC address for just doing that sounds dangerous as duplicate MAC addresses on a network can really create hell in no time. Cheers, Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 17 16:50:55 2000 Delivered-To: freebsd-net@freebsd.org Received: from racine.cybercable.fr (racine.cybercable.fr [212.198.0.201]) by hub.freebsd.org (Postfix) with SMTP id 3E07F37B73E for ; Sat, 17 Jun 2000 16:50:47 -0700 (PDT) (envelope-from root@gits.dyndns.org) Received: (qmail 3203996 invoked from network); 17 Jun 2000 23:50:43 -0000 Received: from r224m65.cybercable.tm.fr (HELO gits.dyndns.org) ([195.132.224.65]) (envelope-sender ) by racine.cybercable.fr (qmail-ldap-1.03) with SMTP for ; 17 Jun 2000 23:50:43 -0000 Received: (from root@localhost) by gits.dyndns.org (8.9.3/8.9.3) id BAA11791 for freebsd-net@FreeBSD.ORG; Sun, 18 Jun 2000 01:50:43 +0200 (CEST) (envelope-from root) From: Cyrille Lefevre Posted-Date: Sun, 18 Jun 2000 01:50:43 +0200 (CEST) Message-Id: <200006172350.BAA11791@gits.dyndns.org> Subject: ipfw: about P:2 packets To: freebsd-net@FreeBSD.ORG Date: Sun, 18 Jun 2000 01:50:43 +0200 (CEST) Reply-To: clefevre@citeweb.net Organization: ACME X-Face: V|+c;4!|B?E%BE^{E6);aI.[<97Zd*>^#%Y5Cxv;%Y[PT-LW3;A:fRrJ8+^k"e7@+30g0YD0*^^3jgyShN7o?a]C la*Zv'5NA,=963bM%J^o]C X-Mailer: ELM [version 2.4ME+ PL77 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org at boot time, I've these messages when, I guess, the route daemon is stated. Jun 15 06:43:36 gits /kernel: ipfw: 65000 Deny P:2 195.132.XXX.65 224.0.0.2 out via ep0 Jun 15 06:43:36 gits /kernel: ipfw: 65000 Deny P:2 195.132.XXX.65 224.0.0.2 in via ep0 Jun 15 06:43:38 gits /kernel: ipfw: 65000 Deny P:2 195.132.XXX.65 224.0.0.9 out via ep0 Jun 15 06:43:38 gits /kernel: ipfw: 65000 Deny P:2 195.132.XXX.65 224.0.0.9 in via ep0 in some words, what are thoses packets ? using ipfw, how to enable them to pass w/o a (not tested) generic rule like : add pass all from $oip to 224.0.0.0/24 add pass all from 224.0.0.0/24 to $oip thanks by advance. Cyrille. -- home: mailto:clefevre@citeweb.net work: mailto:Cyrille.Lefevre@edf.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message