From owner-freebsd-net@FreeBSD.ORG Mon Dec 26 03:04:06 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92EC216A41F; Mon, 26 Dec 2005 03:04:05 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id C552843D49; Mon, 26 Dec 2005 03:04:04 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id jBQ33xrd018408; Mon, 26 Dec 2005 14:03:59 +1100 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id jBQ33uVY029680; Mon, 26 Dec 2005 14:03:56 +1100 Date: Mon, 26 Dec 2005 14:03:57 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Andre Oppermann In-Reply-To: <43AD4540.472AC649@freebsd.org> Message-ID: <20051226133519.Y20444@delplex.bde.org> References: <1135377218.010275.56487.nullmailer@cicuta.babolo.ru> <43AC874E.1010208@elischer.org> <43AD4540.472AC649@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org, Matt Staroscik , Julian Elischer Subject: Re: Good gigabit NIC for 4.11? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2005 03:04:06 -0000 On Sat, 24 Dec 2005, Andre Oppermann wrote: > Julian Elischer wrote: >> >> "."@babolo.ru wrote: >> >>>> I've been Googling up a storm but I am having trouble finding >>>> recommendations for a good gigabit ethernet card to use with 4.11. The >>>> Intel part numbers I found in the em readme are a few years old now, and >>>> I can't quite determine how happy people are with other chipsets despite >>>> my searches. >>>> >>>> I'm looking for a basic PCI 1-port card with jumbo frame support if >>>> possible--I can live without it. Either way, stability is much more >>>> important than performance. >>>> >>>> >>> em for PCI32x33MHz works good up to 250Mbit/s, not more >>> em for PCI64x66MHz works up to about 500Mbit/s without polling > > Please specify the packet size (distribution) you've got these numbers > from. sk and bge for PCI 33MHz under my version of an old version of FreeBSD and significantly modified sk driver: - nfs with default packet size gives 15-30MB/s on a file system where local r/w gives 51-53MB/s. Strangely, tcp is best for writing (30MB/s vs 19 vor udp) and worst for reading (15MB/s vs 23). - sk to bge packet size 5 using ttcp -u: 1.1MB/s 240kpps (2% lost). Either ttcp or sk must be modified to avoid problems with ENOBUFS. - sk to bge packet size 1500 using ttcp -u: 78MB/s 53.4kpps (0% lost). - sk to bge packet size 8192 using ttcp -u: [panic]. Apparently I got bad bits from -current or mismerged them. - bge to sk packet size 5 using ttcp -u: 1.0MB/s 208kpps (0% lost). Different problems with ENOBUFS -- unmodified ttcp spins so test always takes 100% CPU. - bge to sk packet size 1500 using ttcp -u: [bge hangs] > You have to be careful here. Throughput and packets per second are not > directly related. Throughput is generally limited by good/bad hardware > and DMA speed. My measurements show that with decent hardware (em(4) and > bge(4) on PCI-X/133MHz) you can easily run at full wirespeed of 1 gigabit > per second with 1500 bytes per packet as the CPU only has to handle about > 81,000 packets per second. All processing like forwarding, firewalling and PCI/33MHz apparently can't do "only" 81000 non-small packets/sec. > routing table lookups are done once per packet no matter how large it is. > So at wirespeed with 64 bytes packets you've got to do this 1.488 million > times per second. This is a bit harder and entirely CPU bound. With some > mods and fastforward we've got em(4) to do 714,000 packets per second on > my Opteron 852 with PCI-X/133. Hacking em(4) to m_free() the packets just > before they would hit the stack I see that the hardware is capable of > receiving full wirespeed at 64 byte packets. I have timestamps which show that my sk (a Yukon-mumble, whatever is on an A7N8X-E) can't do more than the measured 240kpps. Once the ring buffer is filled up, it takes about 4 usec per packet (typically 1767 usec for 480 packets) to send the packets. I guess it spends the entire 4 usec talking to the PCI bus and perhaps takes several cycles setting up transactions. Bruce From owner-freebsd-net@FreeBSD.ORG Mon Dec 26 03:19:34 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2ABCF16A41F; Mon, 26 Dec 2005 03:19:34 +0000 (GMT) (envelope-from symao@juniper.net) Received: from borg.juniper.net (borg.juniper.net [207.17.137.119]) by mx1.FreeBSD.org (Postfix) with ESMTP id E890143D58; Mon, 26 Dec 2005 03:19:28 +0000 (GMT) (envelope-from symao@juniper.net) Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by borg.juniper.net with ESMTP; 25 Dec 2005 19:19:27 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,293,1131350400"; d="scan'208"; a="519017661:sNHT35886480" Received: from lepton.jnpr.net ([10.208.0.16]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Dec 2005 19:19:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Dec 2005 11:14:39 +0800 Message-ID: <6834BE1811D97C4B8581CE6BD14506800545F0@lepton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Good gigabit NIC for 4.11? Thread-Index: AcYJyRy+IwCG2u/CSjCSS/puTmImhAAADEaQ From: "ShouYan Mao" To: "Bruce Evans" , "Andre Oppermann" X-OriginalArrivalTime: 26 Dec 2005 03:19:27.0007 (UTC) FILETIME=[2D531AF0:01C609CB] Cc: freebsd-net@freebsd.org, Matt Staroscik , Julian Elischer Subject: RE: Good gigabit NIC for 4.11? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2005 03:19:34 -0000 I have setup a machine with the following configurations a few months = ago: (1) Xeon 1.8Ghz (2) 1G DDR2 mem (3) Two Intel 82543GC Gigabit card. The machine works under bridge mode. It can transfer at 300kpps and 1.2Gbit. BTW, the machine has 1 PCI-X 133 bus. But 82543GC can only work at 64bit = * 66Mhz. So the throughput result is at the maximum for 64bit * 66M =3D = 4G, with 60%, at 2.4G =3D 1.2G * 2. If the throughput is above 1.2Gbit/s, the machine begins to drop = packets. If the throughput is less than 1.2Gbit/s, it works well. For big size packets, the bottleneck is at PCI bus, not CPU and memory. If you select 82546 or other cards which can work at 64bit * 133Mhz, I = think the result will be better. If anyone have tried that, please let me know. Shouyan ------------------------------------------------------------ I'm not the best, but I try to do better than last time. ------------------------------------------------------------ -----Original Message----- From: owner-freebsd-net@freebsd.org = [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Bruce Evans Sent: 2005=C4=EA12=D4=C226=C8=D5 11:04 To: Andre Oppermann Cc: freebsd-net@freebsd.org; Matt Staroscik; Julian Elischer Subject: Re: Good gigabit NIC for 4.11? On Sat, 24 Dec 2005, Andre Oppermann wrote: > Julian Elischer wrote: >> >> "."@babolo.ru wrote: >> >>>> I've been Googling up a storm but I am having trouble finding >>>> recommendations for a good gigabit ethernet card to use with 4.11. = The >>>> Intel part numbers I found in the em readme are a few years old = now, and >>>> I can't quite determine how happy people are with other chipsets = despite >>>> my searches. >>>> >>>> I'm looking for a basic PCI 1-port card with jumbo frame support if >>>> possible--I can live without it. Either way, stability is much more >>>> important than performance. >>>> >>>> >>> em for PCI32x33MHz works good up to 250Mbit/s, not more >>> em for PCI64x66MHz works up to about 500Mbit/s without polling > > Please specify the packet size (distribution) you've got these numbers > from. sk and bge for PCI 33MHz under my version of an old version of FreeBSD and significantly modified sk driver: - nfs with default packet size gives 15-30MB/s on a file system where local r/w gives 51-53MB/s. Strangely, tcp is best for writing (30MB/s vs 19 vor udp) and worst for reading (15MB/s vs 23). - sk to bge packet size 5 using ttcp -u: 1.1MB/s 240kpps (2% lost). Either ttcp or sk must be modified to avoid problems with ENOBUFS. - sk to bge packet size 1500 using ttcp -u: 78MB/s 53.4kpps (0% lost). - sk to bge packet size 8192 using ttcp -u: [panic]. Apparently I got bad bits from -current or mismerged them. - bge to sk packet size 5 using ttcp -u: 1.0MB/s 208kpps (0% lost). Different problems with ENOBUFS -- unmodified ttcp spins so test always takes 100% CPU. - bge to sk packet size 1500 using ttcp -u: [bge hangs] > You have to be careful here. Throughput and packets per second are = not > directly related. Throughput is generally limited by good/bad = hardware > and DMA speed. My measurements show that with decent hardware (em(4) = and > bge(4) on PCI-X/133MHz) you can easily run at full wirespeed of 1 = gigabit > per second with 1500 bytes per packet as the CPU only has to handle = about > 81,000 packets per second. All processing like forwarding, = firewalling and PCI/33MHz apparently can't do "only" 81000 non-small packets/sec. > routing table lookups are done once per packet no matter how large it = is. > So at wirespeed with 64 bytes packets you've got to do this 1.488 = million > times per second. This is a bit harder and entirely CPU bound. With = some > mods and fastforward we've got em(4) to do 714,000 packets per second = on > my Opteron 852 with PCI-X/133. Hacking em(4) to m_free() the packets = just > before they would hit the stack I see that the hardware is capable of > receiving full wirespeed at 64 byte packets. I have timestamps which show that my sk (a Yukon-mumble, whatever is on an A7N8X-E) can't do more than the measured 240kpps. Once the ring buffer is filled up, it takes about 4 usec per packet (typically 1767 usec for 480 packets) to send the packets. I guess it spends the entire 4 usec talking to the PCI bus and perhaps takes several cycles setting up transactions. Bruce _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Dec 26 11:02:25 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC55916A41F for ; Mon, 26 Dec 2005 11:02:25 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7889043D5F for ; Mon, 26 Dec 2005 11:02:24 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id jBQB2Ntx018154 for ; Mon, 26 Dec 2005 11:02:23 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id jBQB2MYD018148 for freebsd-net@freebsd.org; Mon, 26 Dec 2005 11:02:22 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 26 Dec 2005 11:02:22 GMT Message-Id: <200512261102.jBQB2MYD018148@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2005 11:02:25 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit o [2005/11/03] kern/88450 net SYN+ACK reports strange size of window 2 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Dec 26 11:44:40 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C546016A41F for ; Mon, 26 Dec 2005 11:44:40 +0000 (GMT) (envelope-from subscriber@osk.com.ua) Received: from gandalf.osk.com.ua (osk.com.ua [195.5.17.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EE7843D49 for ; Mon, 26 Dec 2005 11:44:34 +0000 (GMT) (envelope-from subscriber@osk.com.ua) Received: from localhost (localhost [127.0.0.1]) by gandalf.osk.com.ua (Postfix) with ESMTP id 510DA78C23 for ; Mon, 26 Dec 2005 13:48:40 +0200 (EET) Received: from gandalf.osk.com.ua ([127.0.0.1]) by localhost (gandalf.osk.com.ua [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49043-13 for ; Mon, 26 Dec 2005 13:48:38 +0200 (EET) Received: from OLEG (unknown [192.168.82.111]) by gandalf.osk.com.ua (Postfix) with ESMTP id 5DA8678C22 for ; Mon, 26 Dec 2005 13:48:37 +0200 (EET) Date: Mon, 26 Dec 2005 13:41:50 +0200 From: Oleg Tarasov X-Mailer: The Bat! (v3.0.1.33) Professional X-Priority: 3 (Normal) Message-ID: <1687545235.20051226134150@osk.com.ua> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------5A10119D24A09821" X-Virus-Scanned: amavisd-new at osk.com.ua Subject: Router on 6.0-stable fails to route tcp packets due to NAT?? malfunction X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: FreeBSD MailList List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2005 11:44:40 -0000 ------------5A10119D24A09821 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hello, all SYSTEM DESCRIPTION I have built a production system based on FreeBSD 6.0-stable. The main Internet connection is established using mpd 3.18 which is started by attached script "mpd". It is rcorder'ed similar to ppp-user. mpd configuration is attached in mpd.conf and mpd.links. Shortly, ng0 is a PPPoE connection on rl1 interface. By the way user ppp failed to work with PPPoE connection correctly usually causing "No buffer space available" error which caused all network connections to stop working. Manual restart of ppp helped but it is quite unacceptable for production system. I attach ppp.conf Firewall is configured to manually divert packets to natd. I attach rc.firewall which was simplifyed to a minimum of functions for test purposes. natd is configured using the following config file: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D log no use_sockets yes same_ports yes interface ng0 unregistered_only yes log_ipfw_denied yes log_denied yes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I attach kernel configuration file used to compile it. Here is output of ifconfig: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D rl0: flags=3D8843 mtu 1500 options=3D8 inet 192.168.82.253 netmask 0xffffff00 broadcast 192.168.82.255 ether 00:30:4f:1c:ed:19 media: Ethernet autoselect (100baseTX ) status: active rl1: flags=3D8843 mtu 1500 options=3D8 ether 00:30:4f:1c:ed:17 media: Ethernet autoselect (100baseTX ) status: active plip0: flags=3D108810 mtu 1500 lo0: flags=3D8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 ng0: flags=3D88d1 mtu 1492 inet my.ip.add.ress --> prov.ip.add.ress netmask 0xffffffff =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Here is output of netstat -rn: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Destination Gateway Flags Refs Use Netif Expire default prov.ip.add.ress UGS 0 512334 ng0 my.ip.add.ress lo0 UHS 0 2426 lo0 127.0.0.1 127.0.0.1 UH 0 21881 lo0 192.168.82 link#1 UC 0 0 rl0 192.168.82.253 00:30:4f:1c:ed:19 UHLW 1 1162 lo0 prov.ip.add.ress my.ip.add.ress UH 1 0 ng0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Windows client configuration: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D inet 192.168.82.111 netmask 255.255.255.0 192.168.82.253 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Windows client routing table =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 0.0.0.0 0.0.0.0 192.168.82.253 192.168.82.111 30 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.0.0 255.255.255.0 192.168.82.204 192.168.82.111 1 192.168.82.0 255.255.255.0 192.168.82.111 192.168.82.111 30 192.168.82.111 255.255.255.255 127.0.0.1 127.0.0.1 30 192.168.82.255 255.255.255.255 192.168.82.111 192.168.82.111 30 224.0.0.0 240.0.0.0 192.168.82.111 192.168.82.111 30 255.255.255.255 255.255.255.255 192.168.82.111 192.168.82.111 1 Default gateway: 192.168.82.253 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The system has SQUID, mail, ftp systems and usually direct packet routing was not used so the problem was located after a month of usage of the system. PROBLEM DESCRIPTION I have a number of Windows XP clients in the network which are configured to use This machine as a default gateway. Any icmp packets to Internet work quite normal. Web worked normally too but when using proxy, so packet routing is not used for that. The problem was first encountered when trying to play online game which did not use proxy. Later it was confirmed when trying to serf the Web with usage of proxy turned off. Problem is that almost all data is not transmitted normally using tcp connections. For example trying to open www.gnome.org fails completely but packet flow seems to be normal. The most strange thing is that this problem occurs only on some clients when other ones work quite fine!!! From malfunctioning machines some sites can be opened too!!! Some sites can be opened partitially - some parts like pictures can fail to open. You can say - "How can we be sure that you client machines are configured normally?" - I am system administrator for some years and have plenty of servers and clients confugured by my hands. Also I have a production system based on 5.4p5 which is configured similarly to this one but using kernel ppp for internet connection - but that one had no problems. Everything in the LAN works perfectly. Also everything going through proxy also works fine. Any connection made directly from server has no problems. This makes me think the problem is in routing or NAT. For test purposes I have reinstalled my own client machine (which also has the problem described above) from scratch - no result. I changed network card, changed IP address - no positive result. From=20all above I make a conclusion that possible reason is in the NAT malfunction. Or I dont know what... Here is the dump on both interfaces ng0 and rl0 which are Internet and LAN interfaces. I try to open www.gnome.org and I see this: tcpdump on ng0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 09:55:13.757127 IP (tos 0x0, ttl 127, id 56112, offset 0, flags [DF], proto= : TCP (6), length: 48) piramida.com.ua.1140 > window.gnome.org.http: S, cks= um 0x2b0b (correct), 687058407:687058407(0) win 16384 09:55:13.982233 IP (tos 0x0, ttl 47, id 0, offset 0, flags [DF], proto: TC= P (6), length: 48) window.gnome.org.http > piramida.com.ua.1140: S, cksum 0= x6f48 (correct), 3785163588:3785163588(0) ack 687058408 win 5840 09:55:13.982616 IP (tos 0x0, ttl 127, id 56115, offset 0, flags [DF], proto= : TCP (6), length: 40) piramida.com.ua.1140 > window.gnome.org.http: ., cks= um 0x6e6c (correct), ack 1 win 17520 09:55:13.982774 IP (tos 0x0, ttl 127, id 56116, offset 0, flags [DF], proto= : TCP (6), length: 322) piramida.com.ua.1140 > window.gnome.org.http: P 1:2= 83(282) ack 1 win 17520 09:55:14.219491 IP (tos 0x0, ttl 47, id 58466, offset 0, flags [DF], proto= : TCP (6), length: 40) window.gnome.org.http > piramida.com.ua.1140: ., cks= um 0x98a2 (correct), ack 283 win 6432 09:55:59.300589 IP (tos 0x0, ttl 127, id 62999, offset 0, flags [DF], proto= : TCP (6), length: 40) piramida.com.ua.1140 > window.gnome.org.http: R, cks= um 0xb1be (correct), 283:283(0) ack 1 win 0 09:55:59.417698 IP (tos 0x0, ttl 64, id 36993, offset 0, flags [none], pro= to: TCP (6), length: 40) 192.168.82.111.1140 > window.gnome.org.http: ., ck= sum 0x58ec (correct), ack 3785163589 win 0 ^^^^^^ = ^^^^^^^^^^^^^^^^^^ !!!!!! = !!!!!!!!!!!!!!!!!! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D tcpdump on rl0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 09:55:13.756938 IP (tos 0x0, ttl 128, id 56112, offset 0, flags [DF], proto= : TCP (6), length: 48) 192.168.82.111.1140 > window.gnome.org.http: S, cksu= m 0xd233 (correct), 687058407:687058407(0) win 16384 09:55:13.982399 IP (tos 0x0, ttl 46, id 0, offset 0, flags [DF], proto: TC= P (6), length: 48) window.gnome.org.http > 192.168.82.111.1140: S, cksum 0x= 1671 (correct), 3785163588:3785163588(0) ack 687058408 win 5840 09:55:13.982538 IP (tos 0x0, ttl 128, id 56115, offset 0, flags [DF], proto= : TCP (6), length: 40) 192.168.82.111.1140 > window.gnome.org.http: ., cksu= m 0x1595 (correct), ack 1 win 17520 09:55:13.982719 IP (tos 0x0, ttl 128, id 56116, offset 0, flags [DF], proto= : TCP (6), length: 322) 192.168.82.111.1140 > window.gnome.org.http: P 1:28= 3(282) ack 1 win 17520 09:55:14.219666 IP (tos 0x0, ttl 46, id 58466, offset 0, flags [DF], proto= : TCP (6), length: 40) window.gnome.org.http > 192.168.82.111.1140: ., cksu= m 0x3fcb (correct), ack 283 win 6432 09:55:59.300444 IP (tos 0x0, ttl 128, id 62999, offset 0, flags [DF], proto= : TCP (6), length: 40) 192.168.82.111.1140 > window.gnome.org.http: R, cksu= m 0x58e7 (correct), 283:283(0) ack 1 win 0 09:55:59.417786 IP (tos 0x0, ttl 64, id 36994, offset 0, flags [none], pro= to: TCP (6), length: 40) window.gnome.org.http > 192.168.82.111.1140: ., ck= sum 0x58ec (correct), ack 283 win 0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I am not sure what the hell is happening. The same problem occurs when trying to connect to ftp server - ftp commands work fine but when I'm trying to download file and massive tcp connection forms connection hangs. I would appriciate any useful information on this topic and information on how can I debug this more deeply. --=20 Best regards, Oleg Tarasov mailto:subscriber@osk.com.ua ------------5A10119D24A09821 Content-Type: text/plain; name="dmesg.txt" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="dmesg.txt" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDUgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0 IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAx OTkzLCAxOTk0CiAgICAgICAgVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2Fs aWZvcm5pYS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4KCUZyZWVCU0QgNi4wLVJFTEVBU0UgIzA6 IFR1ZSBOb3YgMjkgMTU6MzI6NTMgRUVUIDIwMDUKCSAgICByb290QGdhbmRhbGYucGlyYW1p ZGEuY29tLnVhOi91c3Ivb2JqL3Vzci9zcmMvc3lzL1BJUkFNSURBCgkgICAgV0FSTklORzog ZGVidWcubXBzYWZlbmV0IGZvcmNlZCB0byAwIGFzIGlwc2VjIHJlcXVpcmVzIEdpYW50Cgkg ICAgV0FSTklORzogTVBTQUZFIG5ldHdvcmsgc3RhY2sgZGlzYWJsZWQsIGV4cGVjdCByZWR1 Y2VkIHBlcmZvcm1hbmNlLgoJICAgIFRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDEx OTMxODIgSHogcXVhbGl0eSAwCgkgICAgQ1BVOiBJbnRlbChSKSBDZWxlcm9uKFRNKSBDUFUg ICAgICAgICAgICAgICAgMTEwME1IeiAoMTA5My45MC1NSHogNjg2LWNsYXNzIENQVSkKCSAg ICAgIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4NmIxICBTdGVwcGluZyA9IDEK CSAgICAgICAgRmVhdHVyZXM9MHgzODNmOWZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFF LE1DRSxDWDgsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixNTVgsRlhTUixTU0U+ CgkJcmVhbCBtZW1vcnkgID0gNDAyNTg3NjQ4ICgzODMgTUIpCgkJYXZhaWwgbWVtb3J5ID0g Mzg0MzM5OTY4ICgzNjYgTUIpCgkJbnB4MDogW0ZBU1RdCgkJbnB4MDogPG1hdGggcHJvY2Vz c29yPiBvbiBtb3RoZXJib2FyZAoJCW5weDA6IElOVCAxNiBpbnRlcmZhY2UKCQlhY3BpMDog PEludGVsUiBBV1JEQUNQST4gb24gbW90aGVyYm9hcmQKCQlhY3BpMDogUG93ZXIgQnV0dG9u IChmaXhlZCkKCQlwY2lfbGluazA6IDxBQ1BJIFBDSSBMaW5rIExOS0E+IGlycSA5IG9uIGFj cGkwCgkJcGNpX2xpbmsxOiA8QUNQSSBQQ0kgTGluayBMTktCPiBpcnEgMTEgb24gYWNwaTAK CQlwY2lfbGluazI6IDxBQ1BJIFBDSSBMaW5rIExOS0M+IGlycSAxMSBvbiBhY3BpMAoJCXBj aV9saW5rMzogPEFDUEkgUENJIExpbmsgTE5LRD4gaXJxIDUgb24gYWNwaTAKCQlwY2lfbGlu azQ6IDxBQ1BJIFBDSSBMaW5rIExOS0U+IGlycSAwIG9uIGFjcGkwCgkJcGNpX2xpbms1OiA8 QUNQSSBQQ0kgTGluayBMTktGPiBpcnEgMCBvbiBhY3BpMAoJCXBjaV9saW5rNjogPEFDUEkg UENJIExpbmsgTE5LMD4gaXJxIDAgb24gYWNwaTAKCQlwY2lfbGluazc6IDxBQ1BJIFBDSSBM aW5rIExOSzE+IGlycSAxMSBvbiBhY3BpMAoJCVRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZy ZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMAoJCWFjcGlfdGltZXIwOiA8MjQtYml0 IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4NDA4LTB4NDBiIG9uIGFjcGkwCgkJY3B1 MDogPEFDUEkgQ1BVPiBvbiBhY3BpMAoJCWFjcGlfdGhyb3R0bGUwOiA8QUNQSSBDUFUgVGhy b3R0bGluZz4gb24gY3B1MAoJCWFjcGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNw aTAKCQlhY3BpX2J1dHRvbjE6IDxTbGVlcCBCdXR0b24+IG9uIGFjcGkwCgkJcGNpYjA6IDxB Q1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMAoJCXBjaTA6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwCgkJYWdwMDogPEludGVsIDgyODE1IChpODE1IEdN Q0gpIGhvc3QgdG8gUENJIGJyaWRnZT4gbWVtIDB4ZTgwMDAwMDAtMHhlYmZmZmZmZiBhdCBk ZXZpY2UgMC4wIG9uIHBjaTAKCQlwY2liMTogPFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2Ug MS4wIG9uIHBjaTAKCQlwY2kxOiA8UENJIGJ1cz4gb24gcGNpYjEKCQlwY2kxOiA8ZGlzcGxh eSwgVkdBPiBhdCBkZXZpY2UgMC4wIChubyBkcml2ZXIgYXR0YWNoZWQpCgkJcGNpYjI6IDxB Q1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMzAuMCBvbiBwY2kwCgkJcGNpMjogPEFD UEkgUENJIGJ1cz4gb24gcGNpYjIKCQlybDA6IDxSZWFsVGVrIDgxMzkgMTAvMTAwQmFzZVRY PiBwb3J0IDB4YzAwMC0weGMwZmYgbWVtIDB4ZWUwMDAwMDAtMHhlZTAwMDBmZiBpcnEgMTEg YXQgZGV2aWNlIDIuMCBvbiBwY2kyCgkJbWlpYnVzMDogPE1JSSBidXM+IG9uIHJsMAoJCXJs cGh5MDogPFJlYWxUZWsgaW50ZXJuYWwgbWVkaWEgaW50ZXJmYWNlPiBvbiBtaWlidXMwCgkJ cmxwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZE WCwgYXV0bwoJCXJsMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MzA6NGY6MWM6ZWQ6MTkKCQly bDA6IFtHSUFOVC1MT0NLRURdCgkJcmwxOiA8UmVhbFRlayA4MTM5IDEwLzEwMEJhc2VUWD4g cG9ydCAweGM0MDAtMHhjNGZmIG1lbSAweGVlMDAxMDAwLTB4ZWUwMDEwZmYgaXJxIDUgYXQg ZGV2aWNlIDMuMCBvbiBwY2kyCgkJbWlpYnVzMTogPE1JSSBidXM+IG9uIHJsMQoJCXJscGh5 MTogPFJlYWxUZWsgaW50ZXJuYWwgbWVkaWEgaW50ZXJmYWNlPiBvbiBtaWlidXMxCgkJcmxw aHkxOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwg YXV0bwoJCXJsMTogRXRoZXJuZXQgYWRkcmVzczogMDA6MzA6NGY6MWM6ZWQ6MTcKCQlybDE6 IFtHSUFOVC1MT0NLRURdCgkJaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDMx LjAgb24gcGNpMAoJCWlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMAoJCWF0YXBjaTA6IDxJbnRl bCBJQ0gyIFVETUExMDAgY29udHJvbGxlcj4gcG9ydCAweDFmMC0weDFmNywweDNmNiwweDE3 MC0weDE3NywweDM3NiwweGYwMDAtMHhmMDBmIGF0IGRldmljZSAzMS4xIG9uIHBjaTAKCQlh dGEwOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMAoJCWF0YTE6IDxBVEEgY2hhbm5lbCAx PiBvbiBhdGFwY2kwCgkJdWhjaTA6IDxJbnRlbCA4MjgwMUJBL0JBTSAoSUNIMikgVVNCIGNv bnRyb2xsZXIgVVNCLUE+IHBvcnQgMHhkMDAwLTB4ZDAxZiBpcnEgNSBhdCBkZXZpY2UgMzEu MiBvbiBwY2kwCgkJdWhjaTA6IFtHSUFOVC1MT0NLRURdCgkJdXNiMDogPEludGVsIDgyODAx QkEvQkFNIChJQ0gyKSBVU0IgY29udHJvbGxlciBVU0ItQT4gb24gdWhjaTAKCQl1c2IwOiBV U0IgcmV2aXNpb24gMS4wCgkJdWh1YjA6IEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkv MCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxCgkJdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92 YWJsZSwgc2VsZiBwb3dlcmVkCgkJcGNpMDogPHNlcmlhbCBidXMsIFNNQnVzPiBhdCBkZXZp Y2UgMzEuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQoJCXVoY2kxOiA8SW50ZWwgODI4MDFCQS9C QU0gKElDSDIpIFVTQiBjb250cm9sbGVyIFVTQi1CPiBwb3J0IDB4ZDgwMC0weGQ4MWYgaXJx IDExIGF0IGRldmljZSAzMS40IG9uIHBjaTAKCQl1aGNpMTogW0dJQU5ULUxPQ0tFRF0KCQl1 c2IxOiA8SW50ZWwgODI4MDFCQS9CQU0gKElDSDIpIFVTQiBjb250cm9sbGVyIFVTQi1CPiBv biB1aGNpMQoJCXVzYjE6IFVTQiByZXZpc2lvbiAxLjAKCQl1aHViMTogSW50ZWwgVUhDSSBy b290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEKCQl1aHViMTogMiBw b3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKCQlwY2kwOiA8bXVsdGltZWRp YSwgYXVkaW8+IGF0IGRldmljZSAzMS41IChubyBkcml2ZXIgYXR0YWNoZWQpCgkJYWNwaV90 ejA6IDxUaGVybWFsIFpvbmU+IG9uIGFjcGkwCgkJZmRjMDogPGZsb3BweSBkcml2ZSBjb250 cm9sbGVyPiBwb3J0IDB4M2YwLTB4M2Y1LDB4M2Y3IGlycSA2IGRycSAyIG9uIGFjcGkwCgkJ ZmRjMDogW0ZBU1RdCgkJZmQwOiA8MTQ0MC1LQiAzLjUiIGRyaXZlPiBvbiBmZGMwIGRyaXZl IDAKCQlzaW8wOiA8MTY1NTBBLWNvbXBhdGlibGUgQ09NIHBvcnQ+IHBvcnQgMHgzZjgtMHgz ZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBhY3BpMAoJCXNpbzA6IHR5cGUgMTY1NTBBCgkJc2lv MTogPDE2NTUwQS1jb21wYXRpYmxlIENPTSBwb3J0PiBwb3J0IDB4MmY4LTB4MmZmIGlycSAz IG9uIGFjcGkwCgkJc2lvMTogdHlwZSAxNjU1MEEKCQlwcGMwOiA8U3RhbmRhcmQgcGFyYWxs ZWwgcHJpbnRlciBwb3J0PiBwb3J0IDB4Mzc4LTB4MzdmIGlycSA3IG9uIGFjcGkwCgkJcHBj MDogR2VuZXJpYyBjaGlwc2V0IChOSUJCTEUtb25seSkgaW4gQ09NUEFUSUJMRSBtb2RlCgkJ cHBidXMwOiA8UGFyYWxsZWwgcG9ydCBidXM+IG9uIHBwYzAKCQlwbGlwMDogPFBMSVAgbmV0 d29yayBpbnRlcmZhY2U+IG9uIHBwYnVzMAoJCWxwdDA6IDxQcmludGVyPiBvbiBwcGJ1czAK CQlscHQwOiBJbnRlcnJ1cHQtZHJpdmVuIHBvcnQKCQlwcGkwOiA8UGFyYWxsZWwgSS9PPiBv biBwcGJ1czAKCQlhdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0 IDB4NjAsMHg2NCBpcnEgMSBvbiBhY3BpMAoJCWF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEg MSBvbiBhdGtiZGMwCgkJa2JkMCBhdCBhdGtiZDAKCQlhdGtiZDA6IFtHSUFOVC1MT0NLRURd CgkJcHNtMDogPFBTLzIgTW91c2U+IGlycSAxMiBvbiBhdGtiZGMwCgkJcHNtMDogW0dJQU5U LUxPQ0tFRF0KCQlwc20wOiBtb2RlbCBOZXRNb3VzZS9OZXRTY3JvbGwgT3B0aWNhbCwgZGV2 aWNlIElEIDAKCQlwbXRpbWVyMCBvbiBpc2EwCgkJc2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0 IGZsYWdzIDB4MTAwIG9uIGlzYTAKCQlzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywg ZmxhZ3M9MHgzMDA+CgkJdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0w eDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMAoJCVRpbWVjb3VudGVyICJUU0Mi IGZyZXF1ZW5jeSAxMDkzOTAyNDQyIEh6IHF1YWxpdHkgODAwCgkJVGltZWNvdW50ZXJzIHRp Y2sgZXZlcnkgMS4wMDAgbXNlYwoJCUlQc2VjOiBJbml0aWFsaXplZCBTZWN1cml0eSBBc3Nv Y2lhdGlvbiBQcm9jZXNzaW5nLgoJCWlwZncyICgraXB2NikgaW5pdGlhbGl6ZWQsIGRpdmVy dCBsb2FkYWJsZSwgcnVsZS1iYXNlZCBmb3J3YXJkaW5nIGVuYWJsZWQsIGRlZmF1bHQgdG8g YWNjZXB0LCBsb2dnaW5nIGxpbWl0ZWQgdG8gMzAwIHBhY2tldHMvZW50cnkgYnkgZGVmYXVs dAoJCWFkMDogMzgyMDRNQiA8U0FNU1VORyBTUDA0MTFOIFRXMTAwLTA4PiBhdCBhdGEwLW1h c3RlciBVRE1BMTAwCgkJYWNkMDogQ0RST00gPEFTVVMgQ0QtUzUyMC9BNC8xLjI+IGF0IGF0 YTEtbWFzdGVyIFVETUEzMwoJCVRyeWluZyB0byBtb3VudCByb290IGZyb20gdWZzOi9kZXYv YWQwczFhCgkJcmwxOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKCQk= ------------5A10119D24A09821 Content-Type: application/octet-stream; name=KERNEL Content-transfer-encoding: base64 Content-Disposition: attachment; filename=KERNEL IwojIEdFTkVSSUMgLS0gR2VuZXJpYyBrZXJuZWwgY29uZmlndXJhdGlvbiBmaWxlIGZvciBG cmVlQlNEL2kzODYKIwojIEZvciBtb3JlIGluZm9ybWF0aW9uIG9uIHRoaXMgZmlsZSwgcGxl YXNlIHJlYWQgdGhlIGhhbmRib29rIHNlY3Rpb24gb24KIyBLZXJuZWwgQ29uZmlndXJhdGlv biBGaWxlczoKIwojICAgIGh0dHA6Ly93d3cuRnJlZUJTRC5vcmcvZG9jL2VuX1VTLklTTzg4 NTktMS9ib29rcy9oYW5kYm9vay9rZXJuZWxjb25maWctY29uZmlnLmh0bWwKIwojIFRoZSBo YW5kYm9vayBpcyBhbHNvIGF2YWlsYWJsZSBsb2NhbGx5IGluIC91c3Ivc2hhcmUvZG9jL2hh bmRib29rCiMgaWYgeW91J3ZlIGluc3RhbGxlZCB0aGUgZG9jIGRpc3RyaWJ1dGlvbiwgb3Ro ZXJ3aXNlIGFsd2F5cyBzZWUgdGhlCiMgRnJlZUJTRCBXb3JsZCBXaWRlIFdlYiBzZXJ2ZXIg KGh0dHA6Ly93d3cuRnJlZUJTRC5vcmcvKSBmb3IgdGhlCiMgbGF0ZXN0IGluZm9ybWF0aW9u LgojCiMgQW4gZXhoYXVzdGl2ZSBsaXN0IG9mIG9wdGlvbnMgYW5kIG1vcmUgZGV0YWlsZWQg ZXhwbGFuYXRpb25zIG9mIHRoZQojIGRldmljZSBsaW5lcyBpcyBhbHNvIHByZXNlbnQgaW4g dGhlIC4uLy4uL2NvbmYvTk9URVMgYW5kIE5PVEVTIGZpbGVzLgojIElmIHlvdSBhcmUgaW4g ZG91YnQgYXMgdG8gdGhlIHB1cnBvc2Ugb3IgbmVjZXNzaXR5IG9mIGEgbGluZSwgY2hlY2sg Zmlyc3QKIyBpbiBOT1RFUy4KIwojICRGcmVlQlNEOiBzcmMvc3lzL2kzODYvY29uZi9HRU5F UklDLHYgMS40MjkuMi4zLjIuMSAyMDA1LzEwLzI4IDE5OjIyOjQxIGpoYiBFeHAgJAoKbWFj aGluZQkJaTM4NgpjcHUJCUk0ODZfQ1BVCmNwdQkJSTU4Nl9DUFUKY3B1CQlJNjg2X0NQVQpp ZGVudAkJUElSQU1JREEKCm9wdGlvbnMgICAgICAgICBTTVAKb3B0aW9ucyAgICAgICAgIElQ RklSRVdBTEwKb3B0aW9ucyAgICAgICAgIElQRklSRVdBTExfVkVSQk9TRQpvcHRpb25zICAg ICAgICAgSVBGSVJFV0FMTF9WRVJCT1NFX0xJTUlUPTMwMApvcHRpb25zICAgICAgICAgSVBG SVJFV0FMTF9ERUZBVUxUX1RPX0FDQ0VQVApvcHRpb25zICAgICAgICAgSVBGSVJFV0FMTF9G T1JXQVJECm9wdGlvbnMgICAgICAgICBJUERJVkVSVApvcHRpb25zICAgICAgICAgSVBTVEVB TFRICm9wdGlvbnMgICAgICAgICBEVU1NWU5FVApvcHRpb25zICAgICAgICAgSFo9MTAwMApv cHRpb25zICAgICAgICAgVkVTQQoKb3B0aW9ucyAgICAgICAgIElQU0VDCm9wdGlvbnMgICAg ICAgICBJUFNFQ19FU1AKb3B0aW9ucyAgICAgICAgIElQU0VDX0RFQlVHCgojIFRvIHN0YXRp Y2FsbHkgY29tcGlsZSBpbiBkZXZpY2Ugd2lyaW5nIGluc3RlYWQgb2YgL2Jvb3QvZGV2aWNl LmhpbnRzCiNoaW50cwkJIkdFTkVSSUMuaGludHMiCQkjIERlZmF1bHQgcGxhY2VzIHRvIGxv b2sgZm9yIGRldmljZXMuCgptYWtlb3B0aW9ucwlERUJVRz0tZwkJIyBCdWlsZCBrZXJuZWwg d2l0aCBnZGIoMSkgZGVidWcgc3ltYm9scwoKI29wdGlvbnMgCVNDSEVEX1VMRQkJIyBVTEUg c2NoZWR1bGVyCm9wdGlvbnMgCVNDSEVEXzRCU0QJCSMgNEJTRCBzY2hlZHVsZXIKb3B0aW9u cyAJUFJFRU1QVElPTgkJIyBFbmFibGUga2VybmVsIHRocmVhZCBwcmVlbXB0aW9uCm9wdGlv bnMgCUlORVQJCQkjIEludGVyTkVUd29ya2luZwojb3B0aW9ucyAJSU5FVDYJCQkjIElQdjYg Y29tbXVuaWNhdGlvbnMgcHJvdG9jb2xzCm9wdGlvbnMgCUZGUwkJCSMgQmVya2VsZXkgRmFz dCBGaWxlc3lzdGVtCm9wdGlvbnMgCVNPRlRVUERBVEVTCQkjIEVuYWJsZSBGRlMgc29mdCB1 cGRhdGVzIHN1cHBvcnQKb3B0aW9ucyAJVUZTX0FDTAkJCSMgU3VwcG9ydCBmb3IgYWNjZXNz IGNvbnRyb2wgbGlzdHMKb3B0aW9ucyAJVUZTX0RJUkhBU0gJCSMgSW1wcm92ZSBwZXJmb3Jt YW5jZSBvbiBiaWcgZGlyZWN0b3JpZXMKb3B0aW9ucyAJTURfUk9PVAkJCSMgTUQgaXMgYSBw b3RlbnRpYWwgcm9vdCBkZXZpY2UKb3B0aW9ucyAJTkZTQ0xJRU5UCQkjIE5ldHdvcmsgRmls ZXN5c3RlbSBDbGllbnQKb3B0aW9ucyAJTkZTU0VSVkVSCQkjIE5ldHdvcmsgRmlsZXN5c3Rl bSBTZXJ2ZXIKb3B0aW9ucyAJTkZTX1JPT1QJCSMgTkZTIHVzYWJsZSBhcyAvLCByZXF1aXJl cyBORlNDTElFTlQKb3B0aW9ucyAJTVNET1NGUwkJCSMgTVNET1MgRmlsZXN5c3RlbQpvcHRp b25zIAlDRDk2NjAJCQkjIElTTyA5NjYwIEZpbGVzeXN0ZW0Kb3B0aW9ucyAJUFJPQ0ZTCQkJ IyBQcm9jZXNzIGZpbGVzeXN0ZW0gKHJlcXVpcmVzIFBTRVVET0ZTKQpvcHRpb25zIAlQU0VV RE9GUwkJIyBQc2V1ZG8tZmlsZXN5c3RlbSBmcmFtZXdvcmsKb3B0aW9ucyAJR0VPTV9HUFQJ CSMgR1VJRCBQYXJ0aXRpb24gVGFibGVzLgpvcHRpb25zIAlDT01QQVRfNDMJCSMgQ29tcGF0 aWJsZSB3aXRoIEJTRCA0LjMgW0tFRVAgVEhJUyFdCm9wdGlvbnMgCUNPTVBBVF9GUkVFQlNE NAkJIyBDb21wYXRpYmxlIHdpdGggRnJlZUJTRDQKb3B0aW9ucyAJQ09NUEFUX0ZSRUVCU0Q1 CQkjIENvbXBhdGlibGUgd2l0aCBGcmVlQlNENQpvcHRpb25zIAlTQ1NJX0RFTEFZPTUwMDAJ CSMgRGVsYXkgKGluIG1zKSBiZWZvcmUgcHJvYmluZyBTQ1NJCm9wdGlvbnMgCUtUUkFDRQkJ CSMga3RyYWNlKDEpIHN1cHBvcnQKb3B0aW9ucyAJU1lTVlNITQkJCSMgU1lTVi1zdHlsZSBz aGFyZWQgbWVtb3J5Cm9wdGlvbnMgCVNZU1ZNU0cJCQkjIFNZU1Ytc3R5bGUgbWVzc2FnZSBx dWV1ZXMKb3B0aW9ucyAJU1lTVlNFTQkJCSMgU1lTVi1zdHlsZSBzZW1hcGhvcmVzCm9wdGlv bnMgCV9LUE9TSVhfUFJJT1JJVFlfU0NIRURVTElORyAjIFBPU0lYIFAxMDAzXzFCIHJlYWwt dGltZSBleHRlbnNpb25zCm9wdGlvbnMgCUtCRF9JTlNUQUxMX0NERVYJIyBpbnN0YWxsIGEg Q0RFViBlbnRyeSBpbiAvZGV2Cm9wdGlvbnMgCUFIQ19SRUdfUFJFVFRZX1BSSU5UCSMgUHJp bnQgcmVnaXN0ZXIgYml0ZmllbGRzIGluIGRlYnVnCgkJCQkJIyBvdXRwdXQuICBBZGRzIH4x MjhrIHRvIGRyaXZlci4Kb3B0aW9ucyAJQUhEX1JFR19QUkVUVFlfUFJJTlQJIyBQcmludCBy ZWdpc3RlciBiaXRmaWVsZHMgaW4gZGVidWcKCQkJCQkjIG91dHB1dC4gIEFkZHMgfjIxNWsg dG8gZHJpdmVyLgpvcHRpb25zIAlBREFQVElWRV9HSUFOVAkJIyBHaWFudCBtdXRleCBpcyBh ZGFwdGl2ZS4KCmRldmljZQkJYXBpYwkJCSMgSS9PIEFQSUMKCiMgQnVzIHN1cHBvcnQuCmRl dmljZQkJZWlzYQpkZXZpY2UJCXBjaQoKIyBGbG9wcHkgZHJpdmVzCmRldmljZQkJZmRjCgoj IEFUQSBhbmQgQVRBUEkgZGV2aWNlcwpkZXZpY2UJCWF0YQpkZXZpY2UJCWF0YWRpc2sJCSMg QVRBIGRpc2sgZHJpdmVzCmRldmljZQkJYXRhcmFpZAkJIyBBVEEgUkFJRCBkcml2ZXMKZGV2 aWNlCQlhdGFwaWNkCQkjIEFUQVBJIENEUk9NIGRyaXZlcwpkZXZpY2UJCWF0YXBpZmQJCSMg QVRBUEkgZmxvcHB5IGRyaXZlcwpkZXZpY2UJCWF0YXBpc3QJCSMgQVRBUEkgdGFwZSBkcml2 ZXMKb3B0aW9ucyAJQVRBX1NUQVRJQ19JRAkjIFN0YXRpYyBkZXZpY2UgbnVtYmVyaW5nCgoj IFNDU0kgQ29udHJvbGxlcnMKZGV2aWNlCQlhaGIJCSMgRUlTQSBBSEExNzQyIGZhbWlseQpk ZXZpY2UJCWFoYwkJIyBBSEEyOTQwIGFuZCBvbmJvYXJkIEFJQzd4eHggZGV2aWNlcwpkZXZp Y2UJCWFoZAkJIyBBSEEzOTMyMC8yOTMyMCBhbmQgb25ib2FyZCBBSUM3OXh4IGRldmljZXMK ZGV2aWNlCQlhbWQJCSMgQU1EIDUzQzk3NCAoVGVrcmFtIERDLTM5MChUKSkKZGV2aWNlCQlp c3AJCSMgUWxvZ2ljIGZhbWlseQojZGV2aWNlIAlpc3BmdwkJIyBGaXJtd2FyZSBmb3IgUUxv Z2ljIEhCQXMtIG5vcm1hbGx5IGEgbW9kdWxlCmRldmljZQkJbXB0CQkjIExTSS1Mb2dpYyBN UFQtRnVzaW9uCiNkZXZpY2UJCW5jcgkJIyBOQ1IvU3ltYmlvcyBMb2dpYwpkZXZpY2UJCXN5 bQkJIyBOQ1IvU3ltYmlvcyBMb2dpYyAobmV3ZXIgY2hpcHNldHMgKyB0aG9zZSBvZiBgbmNy JykKZGV2aWNlCQl0cm0JCSMgVGVrcmFtIERDMzk1VS9VVy9GIERDMzE1VSBhZGFwdGVycwoK ZGV2aWNlCQlhZHYJCSMgQWR2YW5zeXMgU0NTSSBhZGFwdGVycwpkZXZpY2UJCWFkdwkJIyBB ZHZhbnN5cyB3aWRlIFNDU0kgYWRhcHRlcnMKZGV2aWNlCQlhaGEJCSMgQWRhcHRlYyAxNTR4 IFNDU0kgYWRhcHRlcnMKZGV2aWNlCQlhaWMJCSMgQWRhcHRlYyAxNVswMTJdeCBTQ1NJIGFk YXB0ZXJzLCBBSUMtNlsyM102MC4KZGV2aWNlCQlidAkJIyBCdXNsb2dpYy9NeWxleCBNdWx0 aU1hc3RlciBTQ1NJIGFkYXB0ZXJzCgpkZXZpY2UJCW5jdgkJIyBOQ1IgNTNDNTAwCmRldmlj ZQkJbnNwCQkjIFdvcmtiaXQgTmluamEgU0NTSS0zCmRldmljZQkJc3RnCQkjIFRNQyAxOEMz MC8xOEM1MAoKIyBTQ1NJIHBlcmlwaGVyYWxzCmRldmljZQkJc2NidXMJCSMgU0NTSSBidXMg KHJlcXVpcmVkIGZvciBTQ1NJKQpkZXZpY2UJCWNoCQkjIFNDU0kgbWVkaWEgY2hhbmdlcnMK ZGV2aWNlCQlkYQkJIyBEaXJlY3QgQWNjZXNzIChkaXNrcykKZGV2aWNlCQlzYQkJIyBTZXF1 ZW50aWFsIEFjY2VzcyAodGFwZSBldGMpCmRldmljZQkJY2QJCSMgQ0QKZGV2aWNlCQlwYXNz CQkjIFBhc3N0aHJvdWdoIGRldmljZSAoZGlyZWN0IFNDU0kgYWNjZXNzKQpkZXZpY2UJCXNl cwkJIyBTQ1NJIEVudmlyb25tZW50YWwgU2VydmljZXMgKGFuZCBTQUYtVEUpCgojIFJBSUQg Y29udHJvbGxlcnMgaW50ZXJmYWNlZCB0byB0aGUgU0NTSSBzdWJzeXN0ZW0KZGV2aWNlCQlh bXIJCSMgQU1JIE1lZ2FSQUlECmRldmljZQkJYXJjbXNyCQkjIEFyZWNhIFNBVEEgSUkgUkFJ RApkZXZpY2UJCWFzcgkJIyBEUFQgU21hcnRSQUlEIFYsIFZJIGFuZCBBZGFwdGVjIFNDU0kg UkFJRApkZXZpY2UJCWNpc3MJCSMgQ29tcGFxIFNtYXJ0IFJBSUQgNSoKZGV2aWNlCQlkcHQJ CSMgRFBUIFNtYXJ0Y2FjaGUgSUlJLCBJViAtIFNlZSBOT1RFUyBmb3Igb3B0aW9ucwpkZXZp Y2UJCWhwdG12CQkjIEhpZ2hwb2ludCBSb2NrZXRSQUlEIDE4MngKZGV2aWNlCQlpaXIJCSMg SW50ZWwgSW50ZWdyYXRlZCBSQUlECmRldmljZQkJaXBzCQkjIElCTSAoQWRhcHRlYykgU2Vy dmVSQUlECmRldmljZQkJbWx5CQkjIE15bGV4IEFjY2VsZVJBSUQvZVh0cmVtZVJBSUQKZGV2 aWNlCQl0d2EJCSMgM3dhcmUgOTAwMCBzZXJpZXMgUEFUQS9TQVRBIFJBSUQKCiMgUkFJRCBj b250cm9sbGVycwpkZXZpY2UJCWFhYwkJIyBBZGFwdGVjIEZTQSBSQUlECmRldmljZQkJYWFj cAkJIyBTQ1NJIHBhc3N0aHJvdWdoIGZvciBhYWMgKHJlcXVpcmVzIENBTSkKZGV2aWNlCQlp ZGEJCSMgQ29tcGFxIFNtYXJ0IFJBSUQKZGV2aWNlCQltbHgJCSMgTXlsZXggREFDOTYwIGZh bWlseQpkZXZpY2UJCXBzdAkJIyBQcm9taXNlIFN1cGVydHJhayBTWDYwMDAKZGV2aWNlCQl0 d2UJCSMgM3dhcmUgQVRBIFJBSUQKCiMgYXRrYmRjMCBjb250cm9scyBib3RoIHRoZSBrZXli b2FyZCBhbmQgdGhlIFBTLzIgbW91c2UKZGV2aWNlCQlhdGtiZGMJCSMgQVQga2V5Ym9hcmQg Y29udHJvbGxlcgpkZXZpY2UJCWF0a2JkCQkjIEFUIGtleWJvYXJkCmRldmljZQkJcHNtCQkj IFBTLzIgbW91c2UKCmRldmljZQkJdmdhCQkjIFZHQSB2aWRlbyBjYXJkIGRyaXZlcgoKZGV2 aWNlCQlzcGxhc2gJCSMgU3BsYXNoIHNjcmVlbiBhbmQgc2NyZWVuIHNhdmVyIHN1cHBvcnQK CiMgc3lzY29ucyBpcyB0aGUgZGVmYXVsdCBjb25zb2xlIGRyaXZlciwgcmVzZW1ibGluZyBh biBTQ08gY29uc29sZQpkZXZpY2UJCXNjCm9wdGlvbnMgICAgICAgICBTQ19BTFRfTU9VU0Vf SU1BR0UKb3B0aW9ucyAgICAgICAgIFNDX01PVVNFX0NIQVI9MHgzCiNvcHRpb25zICAgICAg ICBTQ19QSVhFTF9NT0RFCm9wdGlvbnMgICAgICAgICBTQ19UV09CVVRUT05fTU9VU0UKCgoj IEVuYWJsZSB0aGlzIGZvciB0aGUgcGN2dCAoVlQyMjAgY29tcGF0aWJsZSkgY29uc29sZSBk cml2ZXIKI2RldmljZQkJdnQKI29wdGlvbnMgCVhTRVJWRVIJCSMgc3VwcG9ydCBmb3IgWCBz ZXJ2ZXIgb24gYSB2dCBjb25zb2xlCiNvcHRpb25zIAlGQVRfQ1VSU09SCSMgc3RhcnQgd2l0 aCBibG9jayBjdXJzb3IKCmRldmljZQkJYWdwCQkjIHN1cHBvcnQgc2V2ZXJhbCBBR1AgY2hp cHNldHMKCiMgUG93ZXIgbWFuYWdlbWVudCBzdXBwb3J0IChzZWUgTk9URVMgZm9yIG1vcmUg b3B0aW9ucykKI2RldmljZQkJYXBtCiMgQWRkIHN1c3BlbmQvcmVzdW1lIHN1cHBvcnQgZm9y IHRoZSBpODI1NC4KZGV2aWNlCQlwbXRpbWVyCgojIFBDQ0FSRCAoUENNQ0lBKSBzdXBwb3J0 CiMgUENNQ0lBIGFuZCBjYXJkYnVzIGJyaWRnZSBzdXBwb3J0CmRldmljZQkJY2JiCQkjIGNh cmRidXMgKHllbnRhKSBicmlkZ2UKZGV2aWNlCQlwY2NhcmQJCSMgUEMgQ2FyZCAoMTYtYml0 KSBidXMKZGV2aWNlCQljYXJkYnVzCQkjIENhcmRCdXMgKDMyLWJpdCkgYnVzCgojIFNlcmlh bCAoQ09NKSBwb3J0cwpkZXZpY2UJCXNpbwkJIyA4MjUwLCAxNls0NV01MCBiYXNlZCBzZXJp YWwgcG9ydHMKCiMgUGFyYWxsZWwgcG9ydApkZXZpY2UJCXBwYwpkZXZpY2UJCXBwYnVzCQkj IFBhcmFsbGVsIHBvcnQgYnVzIChyZXF1aXJlZCkKZGV2aWNlCQlscHQJCSMgUHJpbnRlcgpk ZXZpY2UJCXBsaXAJCSMgVENQL0lQIG92ZXIgcGFyYWxsZWwKZGV2aWNlCQlwcGkJCSMgUGFy YWxsZWwgcG9ydCBpbnRlcmZhY2UgZGV2aWNlCiNkZXZpY2UJCXZwbwkJIyBSZXF1aXJlcyBz Y2J1cyBhbmQgZGEKCiMgSWYgeW91J3ZlIGdvdCBhICJkdW1iIiBzZXJpYWwgb3IgcGFyYWxs ZWwgUENJIGNhcmQgdGhhdCBpcwojIHN1cHBvcnRlZCBieSB0aGUgcHVjKDQpIGdsdWUgZHJp dmVyLCB1bmNvbW1lbnQgdGhlIGZvbGxvd2luZwojIGxpbmUgdG8gZW5hYmxlIGl0IChjb25u ZWN0cyB0byB0aGUgc2lvIGFuZC9vciBwcGMgZHJpdmVycyk6CiNkZXZpY2UJCXB1YwoKIyBQ Q0kgRXRoZXJuZXQgTklDcy4KZGV2aWNlCQlkZQkJIyBERUMvSW50ZWwgREMyMXg0eCAoYGBU dWxpcCcnKQpkZXZpY2UJCWVtCQkjIEludGVsIFBSTy8xMDAwIGFkYXB0ZXIgR2lnYWJpdCBF dGhlcm5ldCBDYXJkCmRldmljZQkJaXhnYgkJIyBJbnRlbCBQUk8vMTBHYkUgRXRoZXJuZXQg Q2FyZApkZXZpY2UJCXR4cAkJIyAzQ29tIDNjUjk5MCAoYGBUeXBob29uJycpCmRldmljZQkJ dngJCSMgM0NvbSAzYzU5MCwgM2M1OTUgKGBgVm9ydGV4JycpCgojIFBDSSBFdGhlcm5ldCBO SUNzIHRoYXQgdXNlIHRoZSBjb21tb24gTUlJIGJ1cyBjb250cm9sbGVyIGNvZGUuCiMgTk9U RTogQmUgc3VyZSB0byBrZWVwIHRoZSAnZGV2aWNlIG1paWJ1cycgbGluZSBpbiBvcmRlciB0 byB1c2UgdGhlc2UgTklDcyEKZGV2aWNlCQltaWlidXMJCSMgTUlJIGJ1cyBzdXBwb3J0CmRl dmljZQkJYmZlCQkjIEJyb2FkY29tIEJDTTQ0MHggMTAvMTAwIEV0aGVybmV0CmRldmljZQkJ YmdlCQkjIEJyb2FkY29tIEJDTTU3MHh4IEdpZ2FiaXQgRXRoZXJuZXQKZGV2aWNlCQlkYwkJ IyBERUMvSW50ZWwgMjExNDMgYW5kIHZhcmlvdXMgd29ya2FsaWtlcwpkZXZpY2UJCWZ4cAkJ IyBJbnRlbCBFdGhlckV4cHJlc3MgUFJPLzEwMEIgKDgyNTU3LCA4MjU1OCkKZGV2aWNlCQls Z2UJCSMgTGV2ZWwgMSBMWFQxMDAxIGdpZ2FiaXQgRXRoZXJuZXQKZGV2aWNlCQluZ2UJCSMg TmF0U2VtaSBEUDgzODIwIGdpZ2FiaXQgRXRoZXJuZXQKZGV2aWNlCQludmUJCSMgblZpZGlh IG5Gb3JjZSBNQ1Agb24tYm9hcmQgRXRoZXJuZXQgTmV0d29ya2luZwpkZXZpY2UJCXBjbgkJ IyBBTUQgQW03OUM5N3ggUENJIDEwLzEwMChwcmVjZWRlbmNlIG92ZXIgJ2xuYycpCmRldmlj ZQkJcmUJCSMgUmVhbFRlayA4MTM5QysvODE2OS84MTY5Uy84MTEwUwpkZXZpY2UJCXJsCQkj IFJlYWxUZWsgODEyOS84MTM5CmRldmljZQkJc2YJCSMgQWRhcHRlYyBBSUMtNjkxNSAoYGBT dGFyZmlyZScnKQpkZXZpY2UJCXNpcwkJIyBTaWxpY29uIEludGVncmF0ZWQgU3lzdGVtcyBT aVMgOTAwL1NpUyA3MDE2CmRldmljZQkJc2sJCSMgU3lzS29ubmVjdCBTSy05ODR4ICYgU0st OTgyeCBnaWdhYml0IEV0aGVybmV0CmRldmljZQkJc3RlCQkjIFN1bmRhbmNlIFNUMjAxIChE LUxpbmsgREZFLTU1MFRYKQpkZXZpY2UJCXRpCQkjIEFsdGVvbiBOZXR3b3JrcyBUaWdvbiBJ L0lJIGdpZ2FiaXQgRXRoZXJuZXQKZGV2aWNlCQl0bAkJIyBUZXhhcyBJbnN0cnVtZW50cyBU aHVuZGVyTEFOCmRldmljZQkJdHgJCSMgU01DIEV0aGVyUG93ZXIgSUkgKDgzYzE3MCBgYEVQ SUMnJykKZGV2aWNlCQl2Z2UJCSMgVklBIFZUNjEyeCBnaWdhYml0IEV0aGVybmV0CmRldmlj ZQkJdnIJCSMgVklBIFJoaW5lLCBSaGluZSBJSQpkZXZpY2UJCXdiCQkjIFdpbmJvbmQgVzg5 Qzg0MEYKZGV2aWNlCQl4bAkJIyAzQ29tIDNjOTB4IChgYEJvb21lcmFuZycnLCBgYEN5Y2xv bmUnJykKCiMgSVNBIEV0aGVybmV0IE5JQ3MuICBwY2NhcmQgTklDcyBpbmNsdWRlZC4KZGV2 aWNlCQljcwkJIyBDcnlzdGFsIFNlbWljb25kdWN0b3IgQ1M4OXgwIE5JQwojICdkZXZpY2Ug ZWQnIHJlcXVpcmVzICdkZXZpY2UgbWlpYnVzJwpkZXZpY2UJCWVkCQkjIE5FWzEyXTAwMCwg U01DIFVsdHJhLCAzYzUwMywgRFM4MzkwIGNhcmRzCmRldmljZQkJZXgJCSMgSW50ZWwgRXRo ZXJFeHByZXNzIFByby8xMCBhbmQgUHJvLzEwKwpkZXZpY2UJCWVwCQkjIEV0aGVybGluayBJ SUkgYmFzZWQgY2FyZHMKZGV2aWNlCQlmZQkJIyBGdWppdHN1IE1CODY5NnggYmFzZWQgY2Fy ZHMKZGV2aWNlCQlpZQkJIyBFdGhlckV4cHJlc3MgOC8xNiwgM0M1MDcsIFN0YXJMQU4gMTAg ZXRjLgpkZXZpY2UJCWxuYwkJIyBORTIxMDAsIE5FMzItVkwgTGFuY2UgRXRoZXJuZXQgY2Fy ZHMKZGV2aWNlCQlzbgkJIyBTTUMncyA5MDAwIHNlcmllcyBvZiBFdGhlcm5ldCBjaGlwcwpk ZXZpY2UJCXhlCQkjIFhpcmNvbSBwY2NhcmQgRXRoZXJuZXQKCiMgSVNBIGRldmljZXMgdGhh dCB1c2UgdGhlIG9sZCBJU0Egc2hpbXMKI2RldmljZQkJbGUKCiMgV2lyZWxlc3MgTklDIGNh cmRzCmRldmljZQkJd2xhbgkJIyA4MDIuMTEgc3VwcG9ydApkZXZpY2UJCWFuCQkjIEFpcm9u ZXQgNDUwMC80ODAwIDgwMi4xMSB3aXJlbGVzcyBOSUNzLgpkZXZpY2UJCWF3aQkJIyBCYXlT dGFjayA2NjAgYW5kIG90aGVycwpkZXZpY2UJCXJhbAkJIyBSYWxpbmsgVGVjaG5vbG9neSBS VDI1MDAgd2lyZWxlc3MgTklDcy4KZGV2aWNlCQl3aQkJIyBXYXZlTEFOL0ludGVyc2lsL1N5 bWJvbCA4MDIuMTEgd2lyZWxlc3MgTklDcy4KI2RldmljZQkJd2wJCSMgT2xkZXIgbm9uIDgw Mi4xMSBXYXZlbGFuIHdpcmVsZXNzIE5JQy4KCiMgUHNldWRvIGRldmljZXMuCmRldmljZQkJ bG9vcAkJIyBOZXR3b3JrIGxvb3BiYWNrCmRldmljZQkJcmFuZG9tCQkjIEVudHJvcHkgZGV2 aWNlCmRldmljZQkJZXRoZXIJCSMgRXRoZXJuZXQgc3VwcG9ydApkZXZpY2UJCXNsCQkjIEtl cm5lbCBTTElQCmRldmljZQkJcHBwCQkjIEtlcm5lbCBQUFAKZGV2aWNlCQl0dW4JCSMgUGFj a2V0IHR1bm5lbC4KZGV2aWNlCQlwdHkJCSMgUHNldWRvLXR0eXMgKHRlbG5ldCBldGMpCmRl dmljZQkJbWQJCSMgTWVtb3J5ICJkaXNrcyIKZGV2aWNlCQlnaWYJCSMgSVB2NiBhbmQgSVB2 NCB0dW5uZWxpbmcKZGV2aWNlCQlmYWl0aAkJIyBJUHY2LXRvLUlQdjQgcmVsYXlpbmcgKHRy YW5zbGF0aW9uKQoKIyBUaGUgYGJwZicgZGV2aWNlIGVuYWJsZXMgdGhlIEJlcmtlbGV5IFBh Y2tldCBGaWx0ZXIuCiMgQmUgYXdhcmUgb2YgdGhlIGFkbWluaXN0cmF0aXZlIGNvbnNlcXVl bmNlcyBvZiBlbmFibGluZyB0aGlzIQojIE5vdGUgdGhhdCAnYnBmJyBpcyByZXF1aXJlZCBm b3IgREhDUC4KZGV2aWNlCQlicGYJCSMgQmVya2VsZXkgcGFja2V0IGZpbHRlcgoKIyBVU0Ig c3VwcG9ydApkZXZpY2UJCXVoY2kJCSMgVUhDSSBQQ0ktPlVTQiBpbnRlcmZhY2UKZGV2aWNl CQlvaGNpCQkjIE9IQ0kgUENJLT5VU0IgaW50ZXJmYWNlCmRldmljZQkJZWhjaQkJIyBFSENJ IFBDSS0+VVNCIGludGVyZmFjZSAoVVNCIDIuMCkKZGV2aWNlCQl1c2IJCSMgVVNCIEJ1cyAo cmVxdWlyZWQpCiNkZXZpY2UJCXVkYnAJCSMgVVNCIERvdWJsZSBCdWxrIFBpcGUgZGV2aWNl cwpkZXZpY2UJCXVnZW4JCSMgR2VuZXJpYwpkZXZpY2UJCXVoaWQJCSMgIkh1bWFuIEludGVy ZmFjZSBEZXZpY2VzIgpkZXZpY2UJCXVrYmQJCSMgS2V5Ym9hcmQKZGV2aWNlCQl1bHB0CQkj IFByaW50ZXIKZGV2aWNlCQl1bWFzcwkJIyBEaXNrcy9NYXNzIHN0b3JhZ2UgLSBSZXF1aXJl cyBzY2J1cyBhbmQgZGEKZGV2aWNlCQl1bXMJCSMgTW91c2UKZGV2aWNlCQl1cmFsCQkjIFJh bGluayBUZWNobm9sb2d5IFJUMjUwMFVTQiB3aXJlbGVzcyBOSUNzCmRldmljZQkJdXJpbwkJ IyBEaWFtb25kIFJpbyA1MDAgTVAzIHBsYXllcgpkZXZpY2UJCXVzY2FubmVyCSMgU2Nhbm5l cnMKIyBVU0IgRXRoZXJuZXQsIHJlcXVpcmVzIG1paWJ1cwpkZXZpY2UJCWF1ZQkJIyBBRE10 ZWsgVVNCIEV0aGVybmV0CmRldmljZQkJYXhlCQkjIEFTSVggRWxlY3Ryb25pY3MgVVNCIEV0 aGVybmV0CmRldmljZQkJY2RjZQkJIyBHZW5lcmljIFVTQiBvdmVyIEV0aGVybmV0CmRldmlj ZQkJY3VlCQkjIENBVEMgVVNCIEV0aGVybmV0CmRldmljZQkJa3VlCQkjIEthd2FzYWtpIExT SSBVU0IgRXRoZXJuZXQKZGV2aWNlCQlydWUJCSMgUmVhbFRlayBSVEw4MTUwIFVTQiBFdGhl cm5ldAoKIyBGaXJlV2lyZSBzdXBwb3J0CmRldmljZQkJZmlyZXdpcmUJIyBGaXJlV2lyZSBi dXMgY29kZQpkZXZpY2UJCXNicAkJIyBTQ1NJIG92ZXIgRmlyZVdpcmUgKFJlcXVpcmVzIHNj YnVzIGFuZCBkYSkKZGV2aWNlCQlmd2UJCSMgRXRoZXJuZXQgb3ZlciBGaXJlV2lyZSAobm9u LXN0YW5kYXJkISkK ------------5A10119D24A09821 Content-Type: application/octet-stream; name=mpd Content-transfer-encoding: base64 Content-Disposition: attachment; filename=mpd IyEvYmluL3NoCiMKIyAkRnJlZUJTRDogcG9ydHMvbmV0L21wZC9maWxlcy9tcGQuc2gsdiAx LjIgMjAwNS8wMi8xNCAyMTo0Njo1NyBhcmNoaWUgRXhwICQKIwojIFBST1ZJREU6IG1wZAoj IFJFUVVJUkU6IG5ldGlmIGlzZG5kCiMgS0VZV09SRDogbm9qYWlsCgojIEFkZCB0aGUgZm9s bG93aW5nIGxpbmUgdG8gL2V0Yy9yYy5jb25mIHRvIGVuYWJsZSBtcGQ6CiMKIyBtcGRfZW5h YmxlPSJZRVMiCiMKCm1wZF9mbGFncz0iLWIiCiNtcGRfZW5hYmxlPSJOTyIKCi4gL2V0Yy9y Yy5zdWJyCgpuYW1lPW1wZApyY3Zhcj1gc2V0X3JjdmFyYAoKcHJlZml4PS91c3IvbG9jYWwK cHJvY25hbWU9JHtwcmVmaXh9L3NiaW4vbXBkCnBpZGZpbGU9L3Zhci9ydW4vbXBkLnBpZAoj cmVxdWlyZWRfZmlsZXM9IiR7cHJlZml4fS9ldGMvbXBkL21wZC5jb25mICR7cHJlZml4fS9l dGMvbXBkL21wZC5saW5rcyIKY29tbWFuZD0iJHtwcmVmaXh9L3NiaW4vbXBkIgpzdGFydF9w b3N0Y21kPSJtcGRfcG9zdGNtZCIKCm1wZF9wb3N0Y21kICgpCnsKCmVjaG8gIldhaXRpbmcg Zm9yIG5nMCB0byBiZSBjcmVhdGVkIgoKdW50aWwgaWZjb25maWcgfCBncmVwIG5nMCA+IG51 bApkbwogICAgd2FpdApkb25lCgplY2hvICJuZzAgc3VjY2Vzc2Z1bGx5IGNyZWF0ZWQiCgpp ZmNvbmZpZyBuZzAgaW5ldCA/bXkuaXAuYWRkLnJlc3M/IG5ldG1hc2sgMHhmZmZmZmZmZiA/ cHJvdi5pcC5hZGQucmVzcz8gbXR1IDE0OTIKfQoKbG9hZF9yY19jb25maWcgJHtuYW1lfQpy dW5fcmNfY29tbWFuZCAiJDEiCgo= ------------5A10119D24A09821 Content-Type: application/octet-stream; name="mpd.conf" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="mpd.conf" ZGVmYXVsdDoKICAgICAgICBsb2FkIHVrcnRlbAoKdWtydGVsOgogICAgICAgIG5ldyAtaSBu ZzAgVWtydGVsX1BQUG9FIFVrcnRlbF9QUFBvRV9saW5rCglzZXQgaWZhY2UgYWRkcnMgbXku aXAuYWRkLnJlc3MgcHJvdi5pcC5hZGQucmVzcwoJc2V0IGlmYWNlIGRpc2FibGUgb24tZGVt YW5kCglzZXQgaWZhY2UgaWRsZSAwCglzZXQgaWZhY2Ugcm91dGUgZGVmYXVsdAoKICAgICAg ICBzZXQgaXBjcCB5ZXMgdmpjb21wCiAgICAgICAgc2V0IGlwY3AgcmFuZ2VzIDAuMC4wLjAv MCAwLjAuMC4wLzAKCiAgICAgICAgc2V0IGJ1bmRsZSBkaXNhYmxlIG11bHRpbGluawogICAg ICAgIHNldCBidW5kbGUgYXV0aG5hbWUgIj8/Pz8/Pz8/Pz8iCiAgICAgICAgc2V0IGJ1bmRs ZSBwYXNzd29yZCAiPz8/Pz8/Pz8/PyIKCiAgICAgICAgc2V0IGxpbmsgbm8gYWNmY29tcCBw cm90b2NvbXAKICAgICAgICBzZXQgbGluayBkaXNhYmxlIHBhcCBjaGFwCiAgICAgICAgc2V0 IGxpbmsgYWNjZXB0IGNoYXAKICAgICAgICBzZXQgbGluayBtdHUgMTQ5MgogICAgICAgIHNl dCBsaW5rIGtlZXAtYWxpdmUgMTAgNjAKICAgICAgICBvcGVuIGlmYWNlCgkJCQkJCQkJCQkJ ------------5A10119D24A09821 Content-Type: application/octet-stream; name="mpd.links" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="mpd.links" VWtydGVsX1BQUG9FX2xpbms6CglzZXQgbGluayB0eXBlIHBwcG9lCglzZXQgcHBwb2UgaWZh Y2UgcmwxCglzZXQgcHBwb2Ugc2VydmljZSAiVWtydGVsZWtvbSIKCXNldCBwcHBvZSBkaXNh YmxlIGluY29taW5nCglzZXQgcHBwb2UgZW5hYmxlIG9yaWdpbmF0ZQoJCQkJCQ== ------------5A10119D24A09821 Content-Type: application/octet-stream; name="ppp.conf" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="ppp.conf" IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMKIyBQUFAgIFNhbXBsZSBDb25maWd1cmF0aW9uIEZpbGUKIyBPcmlnaW5h bGx5IHdyaXR0ZW4gYnkgVG9zaGloYXJ1IE9ITk8KIyBTaW1wbGlmaWVkIDUvMTQvMTk5OSBi eSB3c2VsZkBjZHJvbS5jb20KIwojIFNlZSAvdXNyL3NoYXJlL2V4YW1wbGVzL3BwcC8gZm9y IHNvbWUgZXhhbXBsZXMKIwojICRGcmVlQlNEOiBzcmMvZXRjL3BwcC9wcHAuY29uZix2IDEu MTAgMjAwNC8xMS8xOSAxNzoxMjo1NiBvYnJpZW4gRXhwICQKIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKCmRlZmF1 bHQ6CiAgICBlbmFibGUgZm9yY2Utc2NyaXB0cwogICAgc2V0IGRldmljZSBQUFBvRTpybDEK ICAgIHNldCBzcGVlZCBzeW5jCiAgICBzZXQgbXJ1IDE0OTIKICAgIHNldCBtdHUgMTQ5Mgog ICAgZW5hYmxlIGxxcgogICAgc2V0IGNkIDUKICAgIHNldCBkaWFsCiAgICBzZXQgbG9naW4K ICAgIHNldCByZWRpYWwgMCAwCiMgICAgc2V0IHJlY29ubmVjdCAwIDAKICAgIHNldCB0aW1l b3V0IDAKICAgIHNldCBjdHNydHMgb2ZmCgp1a3J0ZWw6CiAgICAgIAogICAgc2V0IGF1dGhu YW1lICI/Pz8/Pz8/Pz8/IgogICAgc2V0IGF1dGhrZXkgIj8/Pz8/Pz8/PyIKCiAgICBhZGQg ZGVmYXVsdCBISVNBRERSCQkJIyBBZGQgYSAoc3RpY2t5KSBkZWZhdWx0IHJvdXRlCg== ------------5A10119D24A09821 Content-Type: application/octet-stream; name="rc.firewall" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="rc.firewall" IyEvYmluL3NoIC0KIyBTdWNrIGluIHRoZSBjb25maWd1cmF0aW9uIHZhcmlhYmxlcy4KaWYg WyAteiAiJHtzb3VyY2VfcmNfY29uZnNfZGVmaW5lZH0iIF07IHRoZW4KCWlmIFsgLXIgL2V0 Yy9kZWZhdWx0cy9yYy5jb25mIF07IHRoZW4KCQkuIC9ldGMvZGVmYXVsdHMvcmMuY29uZgoJ CXNvdXJjZV9yY19jb25mcwoJZWxpZiBbIC1yIC9ldGMvcmMuY29uZiBdOyB0aGVuCgkJLiAv ZXRjL3JjLmNvbmYKCWZpCmZpCgppZiBbIC1uICIkezF9IiBdOyB0aGVuCglmaXJld2FsbF90 eXBlPSIkezF9IgpmaQoKIyMjIyMjIyMjIyMjCiMgU2V0IHF1aWV0IG1vZGUgaWYgcmVxdWVz dGVkCiMKY2FzZSAke2ZpcmV3YWxsX3F1aWV0fSBpbgpbWXldW0VlXVtTc10pCglmd2NtZD0i L3NiaW4vaXBmdyAtcSIKCTs7CiopCglmd2NtZD0iL3NiaW4vaXBmdyIKCTs7CmVzYWMKCiMj IyMjIyMjIyMjIwojIEZsdXNoIG91dCB0aGUgbGlzdCBiZWZvcmUgd2UgYmVnaW4uCiMKJHtm d2NtZH0gLWYgZmx1c2gKCmNhc2UgJHtmaXJld2FsbF90eXBlfSBpbgpbTW1dW1l5XVtTc11b SWldW01tXVtQcF1bTGxdW0VlXSkKCSMgPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KCSMgVGhpcyBpcyBteSBydWxlc2V0 IGZvciBpcGZ3KDgpLiAyMCBNYXJjaCAyMDA1CgkjID09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CgoJIyBTZXQgdGhlc2Ug dG8geW91ciBvdXRzaWRlIGludGVyZmFjZSBuZXR3b3JrIGFuZCBuZXRtYXNrIGFuZCBpcAoJ b2lmPSJuZzAiCglvaXA9Im15LmlwLmFkZC5yZXNzIgoKCSMgU2V0IHRoZXNlIHRvIHlvdXIg aW5zaWRlIGludGVyZmFjZSBuZXR3b3JrIGFuZCBuZXRtYXNrIGFuZCBpcAoJaWlmPSJybDAi CglpaXA9IjE5Mi4xNjguODIuMjUzIgoJaW5ldD0iMTkyLjE2OC44Mi4wLzI0IgoJCgkjIFNl dHVwIExvb3BiYWNrCgkke2Z3Y21kfSBhZGQgMTEwIHNldCAwIHBhc3MgYWxsIGZyb20gYW55 IHRvIGFueSB2aWEgbG8wCgkke2Z3Y21kfSBhZGQgMTIwIHNldCAwIGRlbnkgYWxsIGZyb20g YW55IHRvIDEyNy4wLjAuMC84Cgkke2Z3Y21kfSBhZGQgMTMwIHNldCAwIGRlbnkgaXAgZnJv bSAxMjcuMC4wLjAvOCB0byBhbnkKCgkke2Z3Y21kfSBhZGQgMjAwIHNldCAxIGRlbnkgbG9n IGlwIGZyb20gYW55IHRvIGFueQoJCgoJJHtmd2NtZH0gYWRkIDUwMDAgc2V0IDAgc2tpcHRv IDEwMDAwIGFsbCBmcm9tIGFueSB0byBhbnkgaW4gcmVjdiAke29pZn0KCSR7ZndjbWR9IGFk ZCA1MDEwIHNldCAwIHNraXB0byAyMDAwMCBhbGwgZnJvbSBhbnkgdG8gYW55IG91dCB4bWl0 ICR7b2lmfQoJJHtmd2NtZH0gYWRkIDUwMjAgc2V0IDAgc2tpcHRvIDMwMDAwIGFsbCBmcm9t IGFueSB0byBhbnkgaW4gcmVjdiAke2lpZn0KCSR7ZndjbWR9IGFkZCA1MDMwIHNldCAwIHNr aXB0byA0MDAwMCBhbGwgZnJvbSBhbnkgdG8gYW55IG91dCB4bWl0ICR7aWlmfSAKCQoJJHtm d2NtZH0gYWRkIDUwODAgc2V0IDAgYWxsb3cgYWxsIGZyb20gYW55IHRvIGFueSB2aWEgcmwx CgoJJHtmd2NtZH0gYWRkIDUxMDAgc2V0IDAgZGVueSBsb2cgYWxsIGZyb20gYW55IHRvIGFu eQoJIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjCgkjIFByb2Nlc3MgcGFja2V0cyBpbiB2aWEgJHtvaWZ9ICMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMKCSMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIwoKCSR7ZndjbWR9IGFkZCAxMDAwMCBzZXQgMCBjb3VudCBhbGwg ZnJvbSBhbnkgdG8gYW55IGluIHJlY3YgJHtvaWZ9CgoJIyBTcG9vZmluZwoJJHtmd2NtZH0g YWRkIDEwMTAwIHNldCAwIGRlbnkgYWxsIGZyb20gYW55IHRvIDE5Mi4xNjguMC4wLzE2IGlu IHZpYSAke29pZn0KCSR7ZndjbWR9IGFkZCAxMDExMCBzZXQgMCBkZW55IGFsbCBmcm9tIDE5 Mi4xNjguMC4wLzE2IHRvIGFueSBpbiB2aWEgJHtvaWZ9CgoJIyBSZXNldCBpZGVudCBpbmNv bWluZyBjb25uZWN0aW9ucwoJJHtmd2NtZH0gYWRkIDEwMjAwIHNldCAwIGRlbnkgbG9nIHRj cCBmcm9tIGFueSB0byBtZSAxMTMgaW4gcmVjdiAke29pZn0gc2V0dXAKCgkjIERlbnkgJiBs b2cgc3VzcGljaW91cyBwYWNrZXRzIChsaWtlIG5tYXAgc2NhbnMpCgkke2Z3Y21kfSBhZGQg MTAyMTAgc2V0IDAgZGVueSBsb2cgdGNwIGZyb20gYW55IHRvIGFueSBpbiB0Y3BmbGFncyBz eW4sZmluCgoJIyBIZXJlIGNvbWVzIE5BVCAqKioqKioqKioqKioqKioqKioqKioqKioKCSR7 ZndjbWR9IGFkZCAxNTAwMCBzZXQgMCBkaXZlcnQgbmF0ZCBhbGwgZnJvbSBhbnkgdG8gbWUg aW4gdmlhICR7b2lmfQoJIyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioKCQoJIyBIZXJlIGNvbWUgdGhlIGR5bmFtaWMgcnVsZXMKCSMgTk9URTogY2hlY2stc3Rh dGUgaGVyZSB3aWxsIGFsc28gcHJvY2VzcyBydWxlcyBjcmVhdGVkIGJ5CgkjIGtlZXAtc3Rh dGUgZnJvbSAiaW4gcmVjdiAke2lpZn0iICEKCSR7ZndjbWR9IGFkZCAxNjAwMCBzZXQgMCBj aGVjay1zdGF0ZQoJJHtmd2NtZH0gYWRkIDE2MDEwIHNldCAwIGRlbnkgdGNwIGZyb20gYW55 IHRvIG1lIGVzdGFibGlzaGVkCgoJIyBOT1RFOiAgbGltaXQgc3JjLWFkZHIgZHN0LWFkZHIg TiAgaXMgZm9yIERvUyBwcm90ZWN0aW9uCgkjIEFsbG93IGFjY2VzcyB0byBvdXIgRlRQICgy MCwyMSksIFNTSCAoMjIpLCBTTVRQICgyNSksIEROUyAoNTMpLCBQT1AzLXNzbCAoOTk1KQoJ JHtmd2NtZH0gc2V0IGRpc2FibGUgMTEKCSR7ZndjbWR9IGFkZCAxNjEwMCBzZXQgMTEgcGFz cyB0Y3AgZnJvbSBhbnkgdG8gbWUgMjAsMjEgaW4gcmVjdiAke29pZn0gc2V0dXAgbGltaXQg c3JjLWFkZHIgNAoJJHtmd2NtZH0gYWRkIDE2MjAwIHNldCAxMiBwYXNzIHRjcCBmcm9tIGFu eSB0byBtZSAyMiBpbiByZWN2ICR7b2lmfSBzZXR1cCBsaW1pdCBzcmMtYWRkciA0Cgkke2Z3 Y21kfSBhZGQgMTYzMDAgc2V0IDEzIHBhc3MgdGNwIGZyb20gYW55IHRvIG1lIDI1IGluIHJl Y3YgJHtvaWZ9IHNldHVwIGtlZXAtc3RhdGUKCSR7ZndjbWR9IGFkZCAxNjQwMCBzZXQgMTQg cGFzcyB0Y3AgZnJvbSBhbnkgdG8gbWUgNTMgaW4gcmVjdiAke29pZn0gc2V0dXAga2VlcC1z dGF0ZQoJJHtmd2NtZH0gYWRkIDE2NTAwIHNldCAxNSBwYXNzIHRjcCBmcm9tIGFueSB0byBt ZSA5OTUgaW4gcmVjdiAke29pZn0gc2V0dXAgbGltaXQgc3JjLWFkZHIgNAoJJHtmd2NtZH0g YWRkIDE2NjAwIHNldCAxNiBwYXNzIHVkcCBmcm9tIGFueSB0byBtZSA1MyBpbiByZWN2ICR7 b2lmfSBrZWVwLXN0YXRlCgoJIyBBbGxvdyBzb21lIGljbXAKCSMgZWNobyByZXBseSAoMCks IGRlc3RpbmF0aW9uIHVucmVhY2hhYmxlICgzKSwgc291cmNlIHF1ZW5jaCAoNCksIGVjaG8g cmVxdWVzdCAKCSMgKDgpLCB0aW1lLXRvLWxpdmUgZXhjZWVkZWQgKDExKSwgSVAgaGVhZGVy IGJhZCAoMTIpCgkjJHtmd2NtZH0gYWRkIDE3MTAwIHNldCAwIHBhc3MgaWNtcCBmcm9tIGFu eSB0byBhbnkgaWNtcHR5cGUgMCwzLDQsOCwxMSwxMgoJIyR7ZndjbWR9IGFkZCAxNzEwMSBz ZXQgMCBkZW55IGljbXAgZnJvbSBhbnkgdG8gYW55Cgkke2Z3Y21kfSBhZGQgMTcxMDAgc2V0 IDAgcGFzcyBpY21wIGZyb20gYW55IHRvIGFueQoKCSMgQWxsb3cgSVAgZnJhZ21lbnRzIHRv IHBhc3MgdGhyb3VnaAoJJHtmd2NtZH0gYWRkIDE3MjAwIHNldCAwIHBhc3MgYWxsIGZyb20g YW55IHRvIGFueSBmcmFnCgoJIyBBbmQgZW5vdWdoCgkke2Z3Y21kfSBhZGQgMTkwMDAgc2V0 IDAgc2tpcHRvIDY1MDAwIGFsbCBmcm9tIGFueSB0byBhbnkgaW4gcmVjdiAke29pZn0KCgkj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMKCSMgUHJvY2VzcyBwYWNrZXRzIG91dCB2aWEgJHtvaWZ9ICMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIwoJIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjCgoJJHtmd2NtZH0gYWRkIDIwMDAwIHNldCAwIGNvdW50IGFsbCBmcm9t IGFueSB0byBhbnkgb3V0IHhtaXQgJHtvaWZ9CgoJIyBTcG9vZmluZwoJJHtmd2NtZH0gYWRk IDIwMTAwIHNldCAwIGRlbnkgYWxsIGZyb20gYW55IHRvIDE5Mi4xNjguMC4wLzE2IG91dCB4 bWl0ICR7b2lmfQoKCgkjIEhlcmUgY29tZXMgTkFUKioqKioqKioqKioqKioqKioqKioKCSR7 ZndjbWR9IGFkZCAyNTAwMCBzZXQgMCBkaXZlcnQgbmF0ZCBhbGwgZnJvbSAke2luZXR9IHRv IGFueSBvdXQgeG1pdCAke29pZn0KCSMgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKgoJCgkjIE5PVEU6IGNoZWNrLXN0YXRlIGhlcmUgZG9lcyBub3RoaW5nLgoJIyBrZWVw LXN0YXRlIGlzIG9ubHkgZm9yIE1FLiBMb2NhbCBuZXQgd2lsbCBub3QgdXNlIGNyZWF0ZWQg cnVsZXMuCgkke2Z3Y21kfSBhZGQgMjYwMDAgc2V0IDAgY2hlY2stc3RhdGUKCSR7ZndjbWR9 IGFkZCAyNjEwMCBzZXQgMCBhbGxvdyB0Y3AgZnJvbSBtZSB0byBhbnkgb3V0IHhtaXQgJHtv aWZ9IGtlZXAtc3RhdGUKCSR7ZndjbWR9IGFkZCAyNjIwMCBzZXQgMCBhbGxvdyB1ZHAgZnJv bSBtZSB0byBhbnkgb3V0IHhtaXQgJHtvaWZ9IGtlZXAtc3RhdGUKCgkjIEFsbG93IHNvbWUg aWNtcAoJIyBlY2hvIHJlcGx5ICgwKSwgZGVzdGluYXRpb24gdW5yZWFjaGFibGUgKDMpLCBz b3VyY2UgcXVlbmNoICg0KSwgZWNobyByZXF1ZXN0IAoJIyAoOCksIHRpbWUtdG8tbGl2ZSBl eGNlZWRlZCAoMTEpLCBJUCBoZWFkZXIgYmFkICgxMikKCSMke2Z3Y21kfSBhZGQgMjYzMDAg c2V0IDAgcGFzcyBpY21wIGZyb20gYW55IHRvIGFueSBpY21wdHlwZSAwLDMsNCw4LDExLDEy CgkjJHtmd2NtZH0gYWRkIDI2MzAxIHNldCAwIGRlbnkgaWNtcCBmcm9tIGFueSB0byBhbnkK CSR7ZndjbWR9IGFkZCAyNjMwMCBzZXQgMCBwYXNzIGljbXAgZnJvbSBhbnkgdG8gYW55CgoJ IyBBbGxvdyBJUCBmcmFnbWVudHMgdG8gcGFzcyB0aHJvdWdoCgkke2Z3Y21kfSBhZGQgMjY0 MDAgc2V0IDAgcGFzcyBhbGwgZnJvbSBhbnkgdG8gYW55IGZyYWcKCQoJIyBFbm91Z2gKCSR7 ZndjbWR9IGFkZCAyOTAwMCBzZXQgMCBza2lwdG8gNjUwMDAgYWxsIGZyb20gYW55IHRvIGFu eSBvdXQgeG1pdCAke29pZn0KCgkjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKCSMgUHJvY2VzcyBwYWNrZXRzIGluIHZpYSAke2lp Zn0gIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwoJIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCgoKCSR7ZndjbWR9IGFkZCAzMDAw MCBzZXQgMCBjb3VudCBhbGwgZnJvbSBhbnkgdG8gYW55IGluIHJlY3YgJHtpaWZ9CgoJJHtm d2NtZH0gYWRkIDM1MDAwIHNldCAwIGNoZWNrLXN0YXRlCgkke2Z3Y21kfSBhZGQgMzUxMDAg c2V0IDAgZGVueSB0Y3AgZnJvbSBhbnkgdG8gbWUgZXN0YWJsaXNoZWQgaW4gcmVjdiAke2lp Zn0KCSR7ZndjbWR9IGFkZCAzNTIwMCBzZXQgMCBhbGxvdyB0Y3AgZnJvbSAke2luZXR9IHRv IGFueSBpbiByZWN2ICR7aWlmfSBzZXR1cCBrZWVwLXN0YXRlCgkke2Z3Y21kfSBhZGQgMzUz MDAgc2V0IDAgYWxsb3cgdWRwIGZyb20gJHtpbmV0fSB0byBhbnkgaW4gcmVjdiAke2lpZn0g a2VlcC1zdGF0ZQoKCSMgQWxsb3cgc29tZSBpY21wCgkjIGVjaG8gcmVwbHkgKDApLCBkZXN0 aW5hdGlvbiB1bnJlYWNoYWJsZSAoMyksIHNvdXJjZSBxdWVuY2ggKDQpLCBlY2hvIHJlcXVl c3QgCgkjICg4KSwgdGltZS10by1saXZlIGV4Y2VlZGVkICgxMSksIElQIGhlYWRlciBiYWQg KDEyKQoJIyR7ZndjbWR9IGFkZCAzNjAwMCBzZXQgMCBwYXNzIGljbXAgZnJvbSBhbnkgdG8g YW55IGljbXB0eXBlIDAsMyw0LDgsMTEsMTIKCSMke2Z3Y21kfSBhZGQgMzYwMDEgc2V0IDAg ZGVueSBpY21wIGZyb20gYW55IHRvIGFueQoJJHtmd2NtZH0gYWRkIDM2MDAwIHNldCAwIHBh c3MgaWNtcCBmcm9tIGFueSB0byBhbnkKCgkjIEFsbG93IElQIGZyYWdtZW50cyB0byBwYXNz IHRocm91Z2gKCSR7ZndjbWR9IGFkZCAzNjEwMCBzZXQgMCBwYXNzIGFsbCBmcm9tIGFueSB0 byBhbnkgZnJhZwoKCSMgRW5vdWdoCgkke2Z3Y21kfSBhZGQgMzkwMDAgc2V0IDAgc2tpcHRv IDY1MDAwIGFsbCBmcm9tIGFueSB0byBhbnkgaW4gcmVjdiAke2lpZn0KCgkjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKCSMgUHJv Y2VzcyBwYWNrZXRzIG91dCB2aWEgJHtpaWZ9ICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwoJ IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjCgoJJHtmd2NtZH0gYWRkIDQwMDAwIHNldCAwIGNvdW50IGFsbCBmcm9tIGFueSB0byBh bnkgb3V0IHhtaXQgJHtpaWZ9CgoJIyBOT1RFOiBvbmx5IHBhY2tldHMgZnJvbSBNRSBoYXZl IG5vIGR5bmFtaWNseSBmb3JtZWQgcnVsZXMgbm93CgoJJHtmd2NtZH0gYWRkIDQ1MDAwIHNl dCAwIGNoZWNrLXN0YXRlCgkke2Z3Y21kfSBhZGQgNDUxMDAgc2V0IDAgYWxsb3cgdGNwIGZy b20gbWUgdG8gYW55IGtlZXAtc3RhdGUKCSR7ZndjbWR9IGFkZCA0NTIwMCBzZXQgMCBhbGxv dyB1ZHAgZnJvbSBtZSB0byBhbnkga2VlcC1zdGF0ZQoJJHtmd2NtZH0gYWRkIDQ1MjUwIHNl dCAwIGFsbG93IGFsbCBmcm9tIGFueSB0byAke2VtdWxlfQoKCSR7ZndjbWR9IGFkZCA0NTMw MCBzZXQgMCBhbGxvdyBhbGwgZnJvbSAxOTIuMTY4LjAuMC8xNiB0byAke2luZXR9IGtlZXAt c3RhdGUKCQoKCSMgQ2xpZW50LWJhbmsuIE5vIHNlbnNlLiBNYWtlIGl0IGNsZWFyLgoJIyR7 ZndjbWR9IGFkZCA0NzMwMCBzZXQgMzAgYWxsb3cgbG9nIHRjcCBmcm9tIGFueSAyMCB0byAk e2luZXR9CgkjIEFuZCB0aGlzIG9uZSBpcyBvbiBwYXNzaXZlIG1vZGU/IFBhY2tldHMgY29t ZSBmcm9tIHBvcnRzIDMwMDAwKwoJIyR7ZndjbWR9IGFkZCA0NzMxMCBzZXQgMzAgYWxsb3cg bG9nIHRjcCBmcm9tIDgwLjI0OS4yMjUuMTEwIHRvICR7aW5ldH0KCgkjIEFsbG93IHNvbWUg aWNtcAoJIyBlY2hvIHJlcGx5ICgwKSwgZGVzdGluYXRpb24gdW5yZWFjaGFibGUgKDMpLCBz b3VyY2UgcXVlbmNoICg0KSwgZWNobyByZXF1ZXN0IAoJIyAoOCksIHRpbWUtdG8tbGl2ZSBl eGNlZWRlZCAoMTEpLCBJUCBoZWFkZXIgYmFkICgxMikKCSMke2Z3Y21kfSBhZGQgNDgwMDAg c2V0IDAgcGFzcyBpY21wIGZyb20gYW55IHRvIGFueSBpY21wdHlwZSAwLDMsNCw4LDExLDEy CgkjJHtmd2NtZH0gYWRkIDQ4MDAxIHNldCAwIGRlbnkgaWNtcCBmcm9tIGFueSB0byBhbnkK CSR7ZndjbWR9IGFkZCA0ODAwMCBzZXQgMCBwYXNzIGljbXAgZnJvbSBhbnkgdG8gYW55CgoJ IyBBbGxvdyBJUCBmcmFnbWVudHMgdG8gcGFzcyB0aHJvdWdoCgkke2Z3Y21kfSBhZGQgNDgx MDAgc2V0IDAgcGFzcyBhbGwgZnJvbSBhbnkgdG8gYW55IGZyYWcKCgkjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwoJIyBUaGF0J3Mg YWxsLCBmb2xrcyBkZW55IGFuZCBsb2cgZXZlcnl0aGluZyAjIyMjIyMjIyMjIyMKCSMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCgkj IFJlamVjdCAmIGxvZyBhbGwgb3RoZXIgdWRwIGNvbm5lY3Rpb25zCgkke2Z3Y21kfSBhZGQg NjUwMDAgc2V0IDUgZGVueSBsb2cgdWRwIGZyb20gYW55IHRvIGFueQoKCSMgUmVqZWN0ICYg bG9nIGV2ZXJ5dGhpbmcgZWxzZQoJJHtmd2NtZH0gYWRkIDY1MTAwIHNldCA1IGRlbnkgbG9n IGFsbCBmcm9tIGFueSB0byBhbnkKCgkjIERpc2FibGUgcnVsZSAyMDAsIG9wZW4gZmlyZXdh bGwgZm9yIHdvcmsKCSR7ZndjbWR9IHNldCBkaXNhYmxlIDEKCSM9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 Cgk7OwoJCiopCglpZiBbIC1yICIke2ZpcmV3YWxsX3R5cGV9IiBdOyB0aGVuCgkJJHtmd2Nt ZH0gJHtmaXJld2FsbF9mbGFnc30gJHtmaXJld2FsbF90eXBlfQoJZmkKCTs7CmVzYWMK ------------5A10119D24A09821-- From owner-freebsd-net@FreeBSD.ORG Mon Dec 26 15:58:43 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22C6C16A41F for ; Mon, 26 Dec 2005 15:58:43 +0000 (GMT) (envelope-from subscriber@osk.com.ua) Received: from gandalf.osk.com.ua (osk.com.ua [195.5.17.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B57743D5E for ; Mon, 26 Dec 2005 15:58:41 +0000 (GMT) (envelope-from subscriber@osk.com.ua) Received: from localhost (localhost [127.0.0.1]) by gandalf.osk.com.ua (Postfix) with ESMTP id AB15B78C1F for ; Mon, 26 Dec 2005 18:02:46 +0200 (EET) Received: from gandalf.osk.com.ua ([127.0.0.1]) by localhost (gandalf.osk.com.ua [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51590-02; Mon, 26 Dec 2005 18:02:46 +0200 (EET) Received: from OLEG (unknown [192.168.82.111]) by gandalf.osk.com.ua (Postfix) with ESMTP id 15D7D78C1C; Mon, 26 Dec 2005 18:02:46 +0200 (EET) Date: Mon, 26 Dec 2005 17:56:31 +0200 From: Oleg Tarasov X-Mailer: The Bat! (v3.0.1.33) Professional X-Priority: 3 (Normal) Message-ID: <1122736554.20051226175631@osk.com.ua> To: FreeBSD MailList In-Reply-To: <1687545235.20051226134150@osk.com.ua> References: <1687545235.20051226134150@osk.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at osk.com.ua Cc: freebsd-net@freebsd.org Subject: Re: Router on 6.0-stable fails to route tcp packets due to NAT?? malfunction X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: FreeBSD MailList List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2005 15:58:43 -0000 Hello, Further analysis brought me to a conclusion that the problem is in MTU values. Changing MTU on client machines made everything work fine - but as I know this is not right. If packets are routed between different MTU interfaces they have to be fragmented or something. If fragmentation is impossible due to "dont fragment" bit set an icmp packet "Need Fragmentation" should be sent to packet sender. As I know web and ftp packets dont have "dont fragment" bit set so packet fragmentation should apply normally what doesn't happen. Reading my firewall configuration we can see that any icmp packets can go freely through it so the reason of such malfunction is unknown to me. Also there are rules that allow passing of fragmented packets freely. Anyway the firewall configuration was copied from another production system which also has different MTU's on interfaces. Can anyone tell me what is the problem? -- Best regards, Oleg Tarasov mailto:subscriber@osk.com.ua From owner-freebsd-net@FreeBSD.ORG Mon Dec 26 18:15:32 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C04B216A41F for ; Mon, 26 Dec 2005 18:15:32 +0000 (GMT) (envelope-from skylar@cs.earlham.edu) Received: from quark.cs.earlham.edu (cs.earlham.edu [159.28.230.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id C472643D5C for ; Mon, 26 Dec 2005 18:15:29 +0000 (GMT) (envelope-from skylar@cs.earlham.edu) Received: from [192.168.0.11] (CPE-67-48-232-40.new.res.rr.com [67.48.232.40]) (authenticated bits=0) by quark.cs.earlham.edu (8.13.4/8.13.3) with ESMTP id jBQIFMEn003486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Dec 2005 13:15:23 -0500 (EST) (envelope-from skylar@cs.earlham.edu) Message-ID: <43B03332.2010904@cs.earlham.edu> Date: Mon, 26 Dec 2005 12:15:14 -0600 From: Skylar Thompson Organization: Earlham College Computer Science Department User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.93.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF65FB0995D74227B5B2C8E01" X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.6 (quark.cs.earlham.edu [159.28.230.3]); Mon, 26 Dec 2005 13:15:24 -0500 (EST) X-Virus-Scanned: ClamAV 0.87.1/1218/Mon Dec 26 08:46:59 2005 on quark.cs.earlham.edu X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.52 on 159.28.230.3 X-Spam-Status: No, score=0.1 required=8.0 tests=RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on quark.cs.earlham.edu Subject: DHCP oddity X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: skylar@cs.earlham.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2005 18:15:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF65FB0995D74227B5B2C8E01 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit While doing some network stress-tests from a dual-CPU x86 FreeBSD 5.4 server, I noticed that a "ping -f" drives dhcpd's CPU usage way up. I put dhcpd into debug mode and didn't get any error messages. I then ran dhcpd with strace, and saw loads of these messages when I started the ping flood: select(8, [?], [?], [?], NULL) = 1 () gettimeofday({...}, NULL) = 0 recvfrom(4, 0xbfbfe090, 1500, 0, {...}, [?]) = 84 select(8, [?], [?], [?], NULL) = 1 () gettimeofday({...}, NULL) = 0 recvfrom(4, 0xbfbfe090, 1500, 0, {...}, [?]) = 84 Does anyone know why this would happen? -- -- Skylar Thompson (skylar@cs.earlham.edu) -- http://www.cs.earlham.edu/~skylar/ --------------enigF65FB0995D74227B5B2C8E01 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDsDM2sc4yyULgN4YRAna3AJ9sR2svv4iI5CFsnIYH6nCNYVlTKACeLXS9 xrdkNDcbEPUz4iI4AIVQOkU= =Zsdw -----END PGP SIGNATURE----- --------------enigF65FB0995D74227B5B2C8E01-- From owner-freebsd-net@FreeBSD.ORG Mon Dec 26 20:45:18 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77D8F16A41F for ; Mon, 26 Dec 2005 20:45:18 +0000 (GMT) (envelope-from swp@swp.pp.ru) Received: from bspu.ab.ru (bspu.ab.ru [212.94.100.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 301F343D5D for ; Mon, 26 Dec 2005 20:45:15 +0000 (GMT) (envelope-from swp@swp.pp.ru) Received: from bspu.ab.ru (localhost.bspu.ab.ru [127.0.0.1]) by bspu.ab.ru (8.13.1/8.13.1) with ESMTP id jBQKjAXb023548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Dec 2005 02:45:10 +0600 (NOVT) (envelope-from swp@swp.pp.ru) Received: from swp.pp.ru (uucp@localhost) by bspu.ab.ru (8.13.1/8.13.1/Submit) with UUCP id jBQKjAwt023547 for freebsd-net@freebsd.org; Tue, 27 Dec 2005 02:45:10 +0600 (NOVT) (envelope-from swp@swp.pp.ru) Received: from swp.pp.ru (swp.bspu.secna.ru [212.192.2.73]) by bspu.secna.ru (8.13.4/8.13.4) with ESMTP id jBQKcIvO068323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 27 Dec 2005 02:38:18 +0600 (NOVT) (envelope-from swp@swp.pp.ru) Received: from swp.pp.ru (localhost [127.0.0.1]) by swp.pp.ru (8.13.4/8.13.4) with ESMTP id jBQKcIVT027382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Dec 2005 02:38:18 +0600 (NOVT) (envelope-from swp@swp.pp.ru) Received: (from root@localhost) by swp.pp.ru (8.13.4/8.13.4/Submit) id jBQKcIdp027381 for freebsd-net@freebsd.org; Tue, 27 Dec 2005 02:38:18 +0600 (NOVT) (envelope-from swp) Date: Tue, 27 Dec 2005 02:38:18 +0600 From: "mitrohin a.s." To: freebsd-net@freebsd.org Message-ID: <20051226203817.GA27151@swp.pp.ru> 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.5.9i Subject: ipfw forward bug? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: swp@swp.pp.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2005 20:45:18 -0000 helo. i have strangle problem with forward rule. isp1 +----------+ <-----[fxp0:x.x.x.1/24] router_1 [re0:10.200.1.1/24]--------+ | [xl2:10.4.2.1/24]---+ | +----------+ | | +--------+ | | | host_1 [10.4.2.121/24]-----------------------+ | +--------+ | | isp2 +----------+ | <-----[xl2:172.16.42.2/24] router_2 [re0:10.200.1.2/24]-----+ +----------+ router_1 propagate defaultroute via fxp0 (isp1) for local network. router_2 have link via xl2 to isp2 and defaultroute to 10.200.1.1. i want to lead external traffic of host_1 via isp2, but have got trouble. router_2 ipfw rules: root@main# ipfw -c show 00100 321246 89176165 allow via lo0 00200 40 2000 deny { src-ip 127.0.0.0/8 or dst-ip 127.0.0.0/8 } 00400 7226 231262 allow dst-ip 224.0.0.0/4 00500 354153 88470867 allow src-ip 10.0.0.0/8 dst-ip 10.0.0.0/8 00600 0 0 check-state 00700 65 5460 skipto 50000 log proto icmp dst-ip 10.4.2.121 in keep-state 00800 0 0 skipto 50000 log proto icmp dst-ip 10.4.2.121 out keep-state 00900 0 0 skipto 50000 log proto icmp src-ip 10.4.2.121 in keep-state 01000 0 0 skipto 50000 log proto icmp src-ip 10.4.2.121 out keep-state 01800 133396 44504758 allow 50000 32 2688 fwd 172.16.42.1 log src-ip 10.4.2.121 in 50100 26445 5425866 allow ! rule 800,900,1000 for test only. make ping from external host now. -bash-2.05b$ ping -c 1 olymp.uni-altai.ru PING olymp.uni-altai.ru (83.246.136.148): 56 data bytes --- olymp.uni-altai.ru ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss ! isp2 cisco make nat 83.246.136.145 to 10.4.2.121 and vise versa. router_2 security.log contain Dec 27 00:52:22 main kernel: ipfw: \ 700 SkipTo 50000 ICMP:8.0 80.71.162.250 10.4.2.121 in via xl2 Dec 27 00:52:22 main kernel: ipfw: \ 700 SkipTo 50000 ICMP:8.0 80.71.162.250 10.4.2.121 out via re0 Dec 27 00:52:22 main kernel: ipfw: \ 700 SkipTo 50000 ICMP:0.0 10.4.2.121 80.71.162.250 in via re0 Dec 27 00:52:22 main kernel: ipfw: \ 50000 Forward to 172.16.42.1 ICMP:0.0 10.4.2.121 80.71.162.250 in via re0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ FORWARD !!! Dec 27 00:52:22 main kernel: ipfw: \ 700 SkipTo 50000 ICMP:0.0 10.4.2.121 80.71.162.250 out via re0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ BUT GO TO DEFAULTROUTE !!! ... ? why "out via re0"? i expect "out via xl2". and loop Dec 27 00:52:22 main kernel: ipfw: 700 SkipTo 50000 ICMP:0.0 10.4.2.121 80.71.162.250 in via re0 Dec 27 00:52:22 main kernel: ipfw: 50000 Forward to 172.16.42.1 ICMP:0.0 10.4.2.121 80.71.162.250 in via re0 Dec 27 00:52:22 main kernel: ipfw: 700 SkipTo 50000 ICMP:0.0 10.4.2.121 80.71.162.250 out via re0 ... Dec 27 00:52:22 main kernel: ipfw: 700 SkipTo 50000 ICMP:0.0 10.4.2.121 80.71.162.250 in via re0 Dec 27 00:52:22 main kernel: ipfw: 50000 Forward to 172.16.42.1 ICMP:0.0 10.4.2.121 80.71.162.250 in via re0 Dec 27 00:52:22 main kernel: ipfw: 700 SkipTo 50000 ICMP:0.0 10.4.2.121 80.71.162.250 out via re0 Dec 27 00:52:22 main kernel: ipfw: 700 SkipTo 50000 ICMP:0.0 10.4.2.121 80.71.162.250 in via re0 Dec 27 00:52:22 main kernel: ipfw: 50000 Forward to 172.16.42.1 ICMP:0.0 10.4.2.121 80.71.162.250 in via re0 Dec 27 00:52:22 main kernel: ipfw: 700 SkipTo 50000 ICMP:0.0 10.4.2.121 80.71.162.250 out via re0 Dec 27 00:52:22 main kernel: ipfw: 700 SkipTo 50000 ICMP:0.0 10.4.2.121 80.71.162.250 in via re0 Dec 27 00:52:22 main kernel: ipfw: 50000 Forward to 172.16.42.1 ICMP:0.0 10.4.2.121 80.71.162.250 in via re0 send-pr? /swp From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 00:29:40 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4BAC16A41F for ; Tue, 27 Dec 2005 00:29:40 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C30C43D66 for ; Tue, 27 Dec 2005 00:29:30 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jBR0TRuG004457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Dec 2005 03:29:28 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jBR0TR5m004456; Tue, 27 Dec 2005 03:29:27 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 27 Dec 2005 03:29:27 +0300 From: Gleb Smirnoff To: Oleg Tarasov Message-ID: <20051227002927.GH1496@FreeBSD.org> Mail-Followup-To: Gleb Smirnoff , Oleg Tarasov , freebsd-net@freebsd.org References: <1687545235.20051226134150@osk.com.ua> <1122736554.20051226175631@osk.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <1122736554.20051226175631@osk.com.ua> User-Agent: Mutt/1.5.6i Cc: freebsd-net@FreeBSD.org Subject: Re: Router on 6.0-stable fails to route tcp packets due to NAT?? malfunction X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2005 00:29:40 -0000 On Mon, Dec 26, 2005 at 05:56:31PM +0200, Oleg Tarasov wrote: O> Further analysis brought me to a conclusion that the problem is in MTU O> values. Changing MTU on client machines made everything work fine - O> but as I know this is not right. If packets are routed between O> different MTU interfaces they have to be fragmented or something. If O> fragmentation is impossible due to "dont fragment" bit set an icmp O> packet "Need Fragmentation" should be sent to packet sender. O> O> As I know web and ftp packets dont have "dont fragment" bit set so O> packet fragmentation should apply normally what doesn't happen. O> O> Reading my firewall configuration we can see that any icmp packets can O> go freely through it so the reason of such malfunction is unknown to O> me. Also there are rules that allow passing of fragmented packets O> freely. Anyway the firewall configuration was copied from another O> production system which also has different MTU's on interfaces. O> O> Can anyone tell me what is the problem? The problem is that you've got a PPPoE link between local net and internet. (internet cloud, MTU 1500)-(your ISP)-[mtu 1492]-(your server)-[mtu 1500]-(your clients). So, when your Windows create a new outgoing connection they set TCP MSS value to 1460, since they don't know about a 1492 MTU link on the way. And this link limits TCP MSS to 1452. There are numerous solutions to fix this: 1) ports/net/tcpmssd - a divert daemon, like natd. You need to divert traffic thru it, and it will alter the TCP MSS value to set limit. 2) ng_tcpmss(4) - a netgraph node, implementing same code in kernel. You usually need ng_ipfw(4) to divert traffic via ng_tcpmss(4) 3) Recently I have committed ng_tcpmss support into mpd, but this code is not yet included into any new release. If you are brave, you can checkout mpd from CVS and use it. It will configure ng_tcpmss node automatically. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 05:24:49 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A818616A41F for ; Tue, 27 Dec 2005 05:24:49 +0000 (GMT) (envelope-from swp@swp.pp.ru) Received: from bspu.ab.ru (bspu.ab.ru [212.94.100.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83F8843D80 for ; Tue, 27 Dec 2005 05:24:38 +0000 (GMT) (envelope-from swp@swp.pp.ru) Received: from bspu.ab.ru (localhost.bspu.ab.ru [127.0.0.1]) by bspu.ab.ru (8.13.1/8.13.1) with ESMTP id jBR5OanN035536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Dec 2005 11:24:36 +0600 (NOVT) (envelope-from swp@swp.pp.ru) Received: from swp.pp.ru (uucp@localhost) by bspu.ab.ru (8.13.1/8.13.1/Submit) with UUCP id jBR5OaUB035535 for freebsd-net@freebsd.org; Tue, 27 Dec 2005 11:24:36 +0600 (NOVT) (envelope-from swp@swp.pp.ru) Received: from swp.pp.ru (swp.bspu.secna.ru [212.192.2.73]) by bspu.secna.ru (8.13.4/8.13.4) with ESMTP id jBR5NNw4084240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 27 Dec 2005 11:23:23 +0600 (NOVT) (envelope-from swp@swp.pp.ru) Received: from swp.pp.ru (localhost [127.0.0.1]) by swp.pp.ru (8.13.4/8.13.4) with ESMTP id jBR5NMiC028943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Dec 2005 11:23:22 +0600 (NOVT) (envelope-from swp@swp.pp.ru) Received: (from swp@localhost) by swp.pp.ru (8.13.4/8.13.4/Submit) id jBR5NMiT028942 for freebsd-net@freebsd.org; Tue, 27 Dec 2005 11:23:22 +0600 (NOVT) (envelope-from swp) Date: Tue, 27 Dec 2005 11:23:22 +0600 From: "mitrohin a.s." To: freebsd-net@freebsd.org Message-ID: <20051227052322.GB28685@swp.pp.ru> Mail-Followup-To: freebsd-net@freebsd.org References: <20051226203817.GA27151@swp.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051226203817.GA27151@swp.pp.ru> User-Agent: Mutt/1.5.9i Subject: Re: ipfw forward bug? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: swp@swp.pp.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2005 05:24:49 -0000 On Tue, Dec 27, 2005 at 02:38:18AM +0600, mitrohin a.s. wrote: > helo. > > i have strangle problem with forward rule. > > isp1 +----------+ > <-----[fxp0:x.x.x.1/24] router_1 [re0:10.200.1.1/24]--------+ > | [xl2:10.4.2.1/24]---+ | > +----------+ | | > +--------+ | | > | host_1 [10.4.2.121/24]-----------------------+ | > +--------+ | > | > isp2 +----------+ | > <-----[xl2:172.16.42.2/24] router_2 [re0:10.200.1.2/24]-----+ > +----------+ > > router_1 propagate defaultroute via fxp0 (isp1) for local network. > router_2 have link via xl2 to isp2 and defaultroute to 10.200.1.1. > i want to lead external traffic of host_1 via isp2, but have got > trouble. > > > router_2 ipfw rules: > > root@main# ipfw -c show > 00100 321246 89176165 allow via lo0 > 00200 40 2000 deny { src-ip 127.0.0.0/8 or dst-ip 127.0.0.0/8 } > 00400 7226 231262 allow dst-ip 224.0.0.0/4 > 00500 354153 88470867 allow src-ip 10.0.0.0/8 dst-ip 10.0.0.0/8 > 00600 0 0 check-state > > 00700 65 5460 skipto 50000 log proto icmp dst-ip 10.4.2.121 in keep-state > 00800 0 0 skipto 50000 log proto icmp dst-ip 10.4.2.121 out keep-state > 00900 0 0 skipto 50000 log proto icmp src-ip 10.4.2.121 in keep-state > 01000 0 0 skipto 50000 log proto icmp src-ip 10.4.2.121 out keep-state > > 01800 133396 44504758 allow > > 50000 32 2688 fwd 172.16.42.1 log src-ip 10.4.2.121 in > 50100 26445 5425866 allow > > ! rule 800,900,1000 for test only. > > > make ping from external host now. > > -bash-2.05b$ ping -c 1 olymp.uni-altai.ru > PING olymp.uni-altai.ru (83.246.136.148): 56 data bytes > > --- olymp.uni-altai.ru ping statistics --- > 1 packets transmitted, 0 packets received, 100% packet loss > > ! isp2 cisco make nat 83.246.136.145 to 10.4.2.121 and vise versa. > > > router_2 security.log contain > > Dec 27 00:52:22 main kernel: ipfw: \ > 700 SkipTo 50000 ICMP:8.0 80.71.162.250 10.4.2.121 in via xl2 > Dec 27 00:52:22 main kernel: ipfw: \ > 700 SkipTo 50000 ICMP:8.0 80.71.162.250 10.4.2.121 out via re0 > Dec 27 00:52:22 main kernel: ipfw: \ > 700 SkipTo 50000 ICMP:0.0 10.4.2.121 80.71.162.250 in via re0 > Dec 27 00:52:22 main kernel: ipfw: \ > 50000 Forward to 172.16.42.1 ICMP:0.0 10.4.2.121 80.71.162.250 in via re0 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ FORWARD !!! > Dec 27 00:52:22 main kernel: ipfw: \ > 700 SkipTo 50000 ICMP:0.0 10.4.2.121 80.71.162.250 out via re0 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ BUT GO TO DEFAULTROUTE !!! ... ? > why "out via re0"? i expect "out via xl2". > > and loop > > Dec 27 00:52:22 main kernel: ipfw: 700 SkipTo 50000 ICMP:0.0 10.4.2.121 80.71.162.250 in via re0 > Dec 27 00:52:22 main kernel: ipfw: 50000 Forward to 172.16.42.1 ICMP:0.0 10.4.2.121 80.71.162.250 in via re0 > Dec 27 00:52:22 main kernel: ipfw: 700 SkipTo 50000 ICMP:0.0 10.4.2.121 80.71.162.250 out via re0 > ... > Dec 27 00:52:22 main kernel: ipfw: 700 SkipTo 50000 ICMP:0.0 10.4.2.121 80.71.162.250 in via re0 > Dec 27 00:52:22 main kernel: ipfw: 50000 Forward to 172.16.42.1 ICMP:0.0 10.4.2.121 80.71.162.250 in via re0 > Dec 27 00:52:22 main kernel: ipfw: 700 SkipTo 50000 ICMP:0.0 10.4.2.121 80.71.162.250 out via re0 > Dec 27 00:52:22 main kernel: ipfw: 700 SkipTo 50000 ICMP:0.0 10.4.2.121 80.71.162.250 in via re0 > Dec 27 00:52:22 main kernel: ipfw: 50000 Forward to 172.16.42.1 ICMP:0.0 10.4.2.121 80.71.162.250 in via re0 > Dec 27 00:52:22 main kernel: ipfw: 700 SkipTo 50000 ICMP:0.0 10.4.2.121 80.71.162.250 out via re0 > Dec 27 00:52:22 main kernel: ipfw: 700 SkipTo 50000 ICMP:0.0 10.4.2.121 80.71.162.250 in via re0 > Dec 27 00:52:22 main kernel: ipfw: 50000 Forward to 172.16.42.1 ICMP:0.0 10.4.2.121 80.71.162.250 in via re0 > > send-pr? and more interesting things here... router_2 ipfw rules: table 1 - internal networks root@main# ipfw table 1 list 10.0.0.0/8 0 83.246.130.168/32 0 83.246.136.144/28 0 172.16.0.0/12 0 192.168.0.0/16 0 table 2 - hosts routed via isp2 1 - allow make connection to external world self root@main# ipfw table 2 list 10.1.3.23/32 1 10.1.3.68/32 1 10.1.3.69/32 1 10.1.3.87/32 0 10.1.3.100/32 1 10.1.3.199/32 1 10.1.3.200/32 1 10.4.2.121/32 0 this is transit hosts for router_2 and traverse chain "in" of rules. root@main# ipfw -c show allow via lo0 deny { src-ip 127.0.0.0/8 or dst-ip 127.0.0.0/8 } allow dst-ip 224.0.0.0/4 allow src-ip table(1) dst-ip table(1) check-state skipto 50000 proto icmp dst-ip table(2) in keep-state skipto 50000 src-ip table(2,1) in keep-state skipto 50000 proto tcp dst-ip 10.1.3.87 dst-port 21,25,80,110,143 in keep-state skipto 50000 proto tcp dst-ip 10.4.2.121 dst-port 80,443 in keep-state deny dst-ip table(2) in allow fwd 172.16.42.1 src-ip table(2) in allow deny ip from any to any this is work for host 10.1.3.83 but not work for host 10.4.2.121. i dont see difference between 10.1.3.87 and 10.4.2.121. may be defaultroute overlap route with 10.4.2.121 only. root@main# uname -a FreeBSD main.uni-altai.ru 6.0-RC1 FreeBSD 6.0-RC1 #0: Sun Oct 16 19:37:36 OMSST 2005 swp@main.uni-altai.ru:/usr/obj/usr/src/sys/ea_kernel i386 sorry for my terrible english. /swp From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 09:28:42 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C75C116A43B for ; Tue, 27 Dec 2005 09:28:42 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74DF043D49 for ; Tue, 27 Dec 2005 09:28:41 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id D975FE6; Tue, 27 Dec 2005 04:29:01 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 9CFA227A9; Tue, 27 Dec 2005 04:29:00 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErB8H-0000gF-Ds; Tue, 27 Dec 2005 09:28:37 +0000 Date: Tue, 27 Dec 2005 09:28:37 +0000 From: Brian Candler To: Oleg Tarasov Message-ID: <20051227092837.GA2564@uk.tiscali.com> References: <1687545235.20051226134150@osk.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1687545235.20051226134150@osk.com.ua> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: Router on 6.0-stable fails to route tcp packets due to NAT?? malfunction X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2005 09:28:43 -0000 On Mon, Dec 26, 2005 at 01:41:50PM +0200, Oleg Tarasov wrote: > mpd configuration is attached in mpd.conf and mpd.links. Shortly, ng0 > is a PPPoE connection on rl1 interface. ^^^^^ Sounds to me like an MTU problem. Windows machine sends a 1500-byte packet, but it can't fit into an ethernet frame along with PPPoE encapsulation, so the router should either send back an ICMP error (if DF bit is set), or it should fragment (if DF bit is not set). With DF, the Windows client is supposed to automatically detect that the path MTU has been exceeded, and try again with a smaller MTU. The tcpdumps you show indicate DF is set. They don't show any ICMP responses, but then again you didn't show the *exact* tcpdump command line you gave. I am guessing you did something like tcpdump -i rl0 tcp port 80 because you let tcpdump perform DNS lookups which means you omitted the -n flag (bad idea), but I don't see the DNS packets going back and forth, which means you had some sort of tcpdump filter which doesn't show DNS packets. Better would be: # tcpdump -i ng0 -n -s 1500 -X host 209.132.176.176 # tcpdump -i rl0 -n -s 1500 -X host 192.168.82.111 so that you see all packets to/from the clients, _including_ ICMP. Something is causing a 'R' (RST) to be sent, terminating the TCP connection. I'm not sure which device this is. Anyway, there's an easy way you can prove whether MTU is the problem or not: on the Windows client, manually set the MTU to something smaller, like 1460. If that works, you know exactly what the problem is. I _think_ your problem is that you are using natd, which is creaking and ancient and maybe does not support NAT for path MTU discovery. But it maybe that PPPoE doesn't support DF properly either. You didn't show your full ipfw ruleset and natd configuration so it's hard to analyse further. Does the PPPoE connection set up some sort of virtual interface, e.g. a 'tun' interface? If so you could try setting a lower MTU on it. Otherwise, personally I would try switching from ipfw/natd to pf. Hope that gives you a few ideas. Brian. From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 10:56:54 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 681CE16A41F for ; Tue, 27 Dec 2005 10:56:54 +0000 (GMT) (envelope-from zhang@ist.osaka-u.ac.jp) Received: from terra.ane.cmc.osaka-u.ac.jp (terra.ane.cmc.osaka-u.ac.jp [133.1.74.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEB1743D55 for ; Tue, 27 Dec 2005 10:56:53 +0000 (GMT) (envelope-from zhang@ist.osaka-u.ac.jp) Received: from [192.168.1.75] (muse.ane.cmc.osaka-u.ac.jp [133.1.74.180]) (authenticated bits=0) by terra.ane.cmc.osaka-u.ac.jp (8.12.10/8.12.10) with ESMTP id jBRAupsN026768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Dec 2005 19:56:51 +0900 Message-ID: <43B11DF3.8070501@ist.osaka-u.ac.jp> Date: Tue, 27 Dec 2005 19:56:51 +0900 From: Zongsheng Zhang User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: tcp performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2005 10:56:54 -0000 Hi, *, For testing throughput of a TCP connection, the following topology is used: Host-A ---GB Ethernet--- Dummynet ---GB Ethernet--- Host-B Host-A/B use FreeBSD v6.0. Sysctl parameters of Host-A/B are: kern.ipc.nmbclusters=32768 net.inet.tcp.inflight.enable=0 net.inet.tcp.sendspace=2097152 # 2M net.inet.tcp.recvspace=2097152 # 2M When RTT in Dummynet is set to 0ms, the throughput (A--B) is about 900Mbps. The buffer size is enough to fill a link bandwidth=800Mbps, and RTT=20ms. However, if RTT is set to 20ms, the throughput is only about 500Mbps. Are there other parameters which are necessary to adjust? Does anyone have suggestion for high throughput? Thanks in advance. -- Zongsheng Zhang zhang@ist.osaka-u.ac.jp From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 13:06:19 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8595B16A41F for ; Tue, 27 Dec 2005 13:06:19 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74B7243D4C for ; Tue, 27 Dec 2005 13:06:18 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id A5E49DA; Tue, 27 Dec 2005 08:06:39 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 7257519D9; Tue, 27 Dec 2005 08:06:38 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErEWs-0000pQ-VL; Tue, 27 Dec 2005 13:06:15 +0000 Date: Tue, 27 Dec 2005 13:06:14 +0000 From: Brian Candler To: Skylar Thompson Message-ID: <20051227130614.GA3148@uk.tiscali.com> References: <43B03332.2010904@cs.earlham.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43B03332.2010904@cs.earlham.edu> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: DHCP oddity X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2005 13:06:19 -0000 On Mon, Dec 26, 2005 at 12:15:14PM -0600, Skylar Thompson wrote: > While doing some network stress-tests from a dual-CPU x86 FreeBSD 5.4 > server, I noticed that a "ping -f" drives dhcpd's CPU usage way up. I > put dhcpd into debug mode and didn't get any error messages. I then ran > dhcpd with strace, and saw loads of these messages when I started the > ping flood: > > select(8, [?], [?], [?], NULL) = 1 () > gettimeofday({...}, NULL) = 0 > recvfrom(4, 0xbfbfe090, 1500, 0, {...}, [?]) = 84 > select(8, [?], [?], [?], NULL) = 1 () > gettimeofday({...}, NULL) = 0 > recvfrom(4, 0xbfbfe090, 1500, 0, {...}, [?]) = 84 > > Does anyone know why this would happen? Were you running tcpdump or similar at the same time, such that the interface was put into promiscuous mode? Check using ifconfig that it is not (i.e. there is no PROMISC flag shown) From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 13:27:05 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B20016A41F for ; Tue, 27 Dec 2005 13:27:05 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B3EA43D53 for ; Tue, 27 Dec 2005 13:27:04 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 163D8E1; Tue, 27 Dec 2005 08:27:26 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id CF8A623B3; Tue, 27 Dec 2005 08:27:24 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErEqz-0000qI-HS; Tue, 27 Dec 2005 13:27:01 +0000 Date: Tue, 27 Dec 2005 13:27:01 +0000 From: Brian Candler To: Zongsheng Zhang Message-ID: <20051227132701.GB3148@uk.tiscali.com> References: <43B11DF3.8070501@ist.osaka-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43B11DF3.8070501@ist.osaka-u.ac.jp> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: tcp performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2005 13:27:05 -0000 On Tue, Dec 27, 2005 at 07:56:51PM +0900, Zongsheng Zhang wrote: > Hi, *, > > For testing throughput of a TCP connection, the following topology is used: > Host-A ---GB Ethernet--- Dummynet ---GB Ethernet--- Host-B > > Host-A/B use FreeBSD v6.0. Sysctl parameters of Host-A/B are: > kern.ipc.nmbclusters=32768 > net.inet.tcp.inflight.enable=0 > net.inet.tcp.sendspace=2097152 # 2M > net.inet.tcp.recvspace=2097152 # 2M > > When RTT in Dummynet is set to 0ms, the throughput (A--B) is about > 900Mbps. The buffer size is enough to fill a link bandwidth=800Mbps, and > RTT=20ms. However, if RTT is set to 20ms, the throughput is only about > 500Mbps. I don't understand what you mean by "the throughput is about 900Mbps... the buffer size is enough to fill a link bandwidth=800Mbps". What buffer size? What have you actually measured, and how have you measured it? By "RTT is set to 20ms" do you mean "dummynet delay is set to 20ms in one direction only", or "dummynet delay is set to 10ms both ways", or something else? Assuming you're not using jumbo frames, a single datagram contains 1460 bytes of payload, 40 bytes of IP header, 16 bytes of ethernet header and FCS, and a little bit of framing (I'm not sure exactly how much) So 2097152 bytes will take 1436.4 frames, giving a total of at least (2097152/1460) * 1516 * 8 = 17,420,725 bits The actual time to transmit this much data at 1,000,000,000 bits per second is 17.4 ms. If your dummynet delay is more than this, then you will not be able to keep the send pipeline full. Put another way: your delay.bandwidth product is 0.02 secs * 1000000000 bits/sec * 1/8 bytes per bit * (1460/1516) = 2,407,651 bytes so I would expect your sendspace needs to be at least that to keep the pipeline full. This is a very simplistic analysis, someone else please feel free to substitute a more thorough one :-) Regards, Brian. From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 15:57:49 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB4B616A420; Tue, 27 Dec 2005 15:57:49 +0000 (GMT) (envelope-from subscriber@osk.com.ua) Received: from gandalf.osk.com.ua (osk.com.ua [195.5.17.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9713F43D8A; Tue, 27 Dec 2005 15:57:40 +0000 (GMT) (envelope-from subscriber@osk.com.ua) Received: from localhost (localhost [127.0.0.1]) by gandalf.osk.com.ua (Postfix) with ESMTP id C4DC178C1D; Tue, 27 Dec 2005 18:01:37 +0200 (EET) Received: from gandalf.osk.com.ua ([127.0.0.1]) by localhost (gandalf.osk.com.ua [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58954-10; Tue, 27 Dec 2005 18:01:37 +0200 (EET) Received: from OLEG (unknown [192.168.82.111]) by gandalf.osk.com.ua (Postfix) with ESMTP id 0B41178C1C; Tue, 27 Dec 2005 18:01:36 +0200 (EET) Date: Tue, 27 Dec 2005 17:55:19 +0200 From: Oleg Tarasov X-Mailer: The Bat! (v3.0.1.33) Professional X-Priority: 3 (Normal) Message-ID: <1945317870.20051227175519@osk.com.ua> To: Gleb Smirnoff In-Reply-To: <20051227002927.GH1496@FreeBSD.org> References: <1687545235.20051226134150@osk.com.ua> <1122736554.20051226175631@osk.com.ua> <20051227002927.GH1496@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at osk.com.ua Cc: freebsd-net@FreeBSD.org Subject: Re: Router on 6.0-stable fails to route tcp packets due to NAT?? malfunction X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: FreeBSD MailList List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2005 15:57:50 -0000 Hello, Gleb Smirnoff wrote: > The problem is that you've got a PPPoE link between local net and internet. > (internet cloud, MTU 1500)-(your ISP)-[mtu 1492]-(your server)-[mtu 1500]-(your > clients). > So, when your Windows create a new outgoing connection they set TCP MSS > value to 1460, since they don't know about a 1492 MTU link on the way. > And this link limits TCP MSS to 1452. > There are numerous solutions to fix this: > 1) ports/net/tcpmssd - a divert daemon, like natd. You need to divert > traffic thru it, and it will alter the TCP MSS value to set limit. > 2) ng_tcpmss(4) - a netgraph node, implementing same code in kernel. > You usually need ng_ipfw(4) to divert traffic via ng_tcpmss(4) > 3) Recently I have committed ng_tcpmss support into mpd, but this > code is not yet included into any new release. If you are brave, > you can checkout mpd from CVS and use it. It will configure ng_tcpmss > node automatically. I have analysed the problem further and came to a conclusion that my ISP's server is blocking ICMP type 3 packets what leads to the malfunction. I have the latest version of ported mpd (3.18_3) installed and tried to insert set iface enable tcpmssfix but no positive result, but I understand that this option should help in this situation. Can you possibly tell me what am I doing wrong? I'll say again that setting MTU on client machine to 1492 helps. What can be the reason for tcpmssfix option not to be working? Maybe there should be an additional kernel module loaded? I didnt find any words mentioning usage of tcpmssfix in mpd's log file. -- Best regards, Oleg Tarasov mailto:subscriber@osk.com.ua From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 16:43:17 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D73016A41F for ; Tue, 27 Dec 2005 16:43:17 +0000 (GMT) (envelope-from skylar@cs.earlham.edu) Received: from quark.cs.earlham.edu (cs.earlham.edu [159.28.230.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id C53D143D55 for ; Tue, 27 Dec 2005 16:43:15 +0000 (GMT) (envelope-from skylar@cs.earlham.edu) Received: from [192.168.0.11] (CPE-67-48-232-40.new.res.rr.com [67.48.232.40]) (authenticated bits=0) by quark.cs.earlham.edu (8.13.4/8.13.3) with ESMTP id jBRGg2Ii003118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Dec 2005 11:43:11 -0500 (EST) (envelope-from skylar@cs.earlham.edu) Message-ID: <43B16ED4.9060803@cs.earlham.edu> Date: Tue, 27 Dec 2005 10:41:56 -0600 From: Skylar Thompson Organization: Earlham College Computer Science Department User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Candler References: <43B03332.2010904@cs.earlham.edu> <20051227130614.GA3148@uk.tiscali.com> In-Reply-To: <20051227130614.GA3148@uk.tiscali.com> X-Enigmail-Version: 0.93.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC7C37149442DD4594104A43D" X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.6 (quark.cs.earlham.edu [159.28.230.3]); Tue, 27 Dec 2005 11:43:12 -0500 (EST) X-Virus-Scanned: ClamAV 0.87.1/1218/Mon Dec 26 08:46:59 2005 on quark.cs.earlham.edu X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.52 on 159.28.230.3 X-Spam-Status: No, score=0.1 required=8.0 tests=RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on quark.cs.earlham.edu Cc: freebsd-net@freebsd.org Subject: Re: DHCP oddity X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: skylar@cs.earlham.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2005 16:43:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC7C37149442DD4594104A43D Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian Candler wrote: >On Mon, Dec 26, 2005 at 12:15:14PM -0600, Skylar Thompson wrote: > > >>While doing some network stress-tests from a dual-CPU x86 FreeBSD 5.4 >>server, I noticed that a "ping -f" drives dhcpd's CPU usage way up. I >>put dhcpd into debug mode and didn't get any error messages. I then ran >>dhcpd with strace, and saw loads of these messages when I started the >>ping flood: >> >>select(8, [?], [?], [?], NULL) = 1 () >>gettimeofday({...}, NULL) = 0 >>recvfrom(4, 0xbfbfe090, 1500, 0, {...}, [?]) = 84 >>select(8, [?], [?], [?], NULL) = 1 () >>gettimeofday({...}, NULL) = 0 >>recvfrom(4, 0xbfbfe090, 1500, 0, {...}, [?]) = 84 >> >>Does anyone know why this would happen? >> >> > >Were you running tcpdump or similar at the same time, such that the >interface was put into promiscuous mode? > >Check using ifconfig that it is not (i.e. there is no PROMISC flag shown) >_______________________________________________ > > No. Here's the setup of the NIC: bge0: flags=8843 mtu 1500 options=1a inet 159.28.234.1 netmask 0xffffff00 broadcast 159.28.234.255 inet6 fe80::210:18ff:fe11:ea1f%bge0 prefixlen 64 scopeid 0x1 ether 00:10:18:11:ea:1f media: Ethernet autoselect (1000baseTX ) status: active I've also tried this using the on-board 100Mbps fxp adapter, and I get the same results. -- -- Skylar Thompson (skylar@cs.earlham.edu) -- http://www.cs.earlham.edu/~skylar/ --------------enigC7C37149442DD4594104A43D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDsW7Ysc4yyULgN4YRAsMhAJ9Sehsb3A1QSVR/K/wswzfQmB5q9gCcDbdm cMnFCcoyGUGYrWKLegEDXTY= =dPt/ -----END PGP SIGNATURE----- --------------enigC7C37149442DD4594104A43D-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 19:31:59 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69B3216A41F for ; Tue, 27 Dec 2005 19:31:59 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A9C343D7B for ; Tue, 27 Dec 2005 19:31:52 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jBRJVmIE020050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Dec 2005 22:31:49 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jBRJVm6K020049; Tue, 27 Dec 2005 22:31:48 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 27 Dec 2005 22:31:48 +0300 From: Gleb Smirnoff To: Oleg Tarasov Message-ID: <20051227193148.GP1496@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Oleg Tarasov , freebsd-net@FreeBSD.org References: <1687545235.20051226134150@osk.com.ua> <1122736554.20051226175631@osk.com.ua> <20051227002927.GH1496@FreeBSD.org> <1945317870.20051227175519@osk.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <1945317870.20051227175519@osk.com.ua> User-Agent: Mutt/1.5.6i Cc: freebsd-net@FreeBSD.org Subject: Re: Router on 6.0-stable fails to route tcp packets due to NAT?? malfunction X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2005 19:31:59 -0000 On Tue, Dec 27, 2005 at 05:55:19PM +0200, Oleg Tarasov wrote: O> I have analysed the problem further and came to a conclusion that my O> ISP's server is blocking ICMP type 3 packets what leads to the O> malfunction. O> O> I have the latest version of ported mpd (3.18_3) installed and tried O> to insert O> set iface enable tcpmssfix O> but no positive result, but I understand that this option should help O> in this situation. Unfortunately this options will not help in your situation. It affects only the packets received on the mpd's interface, while you need to alter outgoing packets. I have fixed this in mpd CVS, but this isn't included in any release yet. However, if you are experienced enough with CVS you can grab and compile sources yourself. O> Can you possibly tell me what am I doing wrong? O> I'll say again that setting MTU on client machine to 1492 helps. O> What can be the reason for tcpmssfix option not to be working? Maybe O> there should be an additional kernel module loaded? I didnt find any O> words mentioning usage of tcpmssfix in mpd's log file. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 03:54:17 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BC0A16A41F for ; Wed, 28 Dec 2005 03:54:17 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id C581943D58 for ; Wed, 28 Dec 2005 03:54:16 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 38C195DBC; Tue, 27 Dec 2005 22:54:16 -0500 (EST) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05940-01; Tue, 27 Dec 2005 22:54:15 -0500 (EST) Received: from [192.168.1.3] (pool-68-161-122-227.ny325.east.verizon.net [68.161.122.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 1DE4E5CFE; Tue, 27 Dec 2005 22:54:15 -0500 (EST) Message-ID: <43B20C73.6040107@mac.com> Date: Tue, 27 Dec 2005 22:54:27 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: skylar@cs.earlham.edu References: <43B03332.2010904@cs.earlham.edu> In-Reply-To: <43B03332.2010904@cs.earlham.edu> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: freebsd-net@freebsd.org Subject: Re: DHCP oddity X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 03:54:17 -0000 Skylar Thompson wrote: > While doing some network stress-tests from a dual-CPU x86 FreeBSD 5.4 > server, I noticed that a "ping -f" drives dhcpd's CPU usage way up. I > put dhcpd into debug mode and didn't get any error messages. I then ran > dhcpd with strace, and saw loads of these messages when I started the > ping flood: > > select(8, [?], [?], [?], NULL) = 1 () > gettimeofday({...}, NULL) = 0 > recvfrom(4, 0xbfbfe090, 1500, 0, {...}, [?]) = 84 > select(8, [?], [?], [?], NULL) = 1 () > gettimeofday({...}, NULL) = 0 > recvfrom(4, 0xbfbfe090, 1500, 0, {...}, [?]) = 84 > > Does anyone know why this would happen? Flood-pinging a machine will stress many things which look at raw packets. At a guess, dhcpd isn't using a PCAP/BPF filter (*) to restrict itself to only paying attention to the traffic which it should care about, so it has to spend CPU in userland to process and discard all of the extra traffic. -- -Chuck (*): I suppose you need to pay attention to ICMP too, if you are going to ping-test IPs before assigning leases. Something like (arp or icmp or port 67)? From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 05:28:14 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8495F16A41F; Wed, 28 Dec 2005 05:28:14 +0000 (GMT) (envelope-from beastie@mra.co.id) Received: from mx1.mra.co.id (mx1.mra.co.id [202.51.19.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0ADEA43D4C; Wed, 28 Dec 2005 05:28:12 +0000 (GMT) (envelope-from beastie@mra.co.id) Received: from localhost (localhost.mra.co.id [127.0.0.1]) by mx1.mra.co.id (Postfix) with ESMTP id 13CCF72456; Tue, 27 Dec 2005 15:09:57 +0700 (WIT) Received: from mx1.mra.co.id ([127.0.0.1]) by localhost (mx1.mra.co.id [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24359-10; Tue, 27 Dec 2005 15:09:56 +0700 (WIT) Received: from [172.16.0.228] (unknown [172.16.0.228]) by mx1.mra.co.id (Postfix) with ESMTP id 9FB6F7246F; Tue, 27 Dec 2005 15:09:56 +0700 (WIT) Message-ID: <43B0F8B4.6030701@mra.co.id> Date: Tue, 27 Dec 2005 15:17:56 +0700 From: Beastie User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051013 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-questions@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mra.co.id Cc: Subject: ipwcontrol load firmware on boot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 05:28:14 -0000 Dear lists; I tried to do network auto configuration by DHCP with integrated Intel Pro Wireless 2100 wlan device (ipw2100). I have trouble when load firmware with ipwcontrol on boot. Initialitation script (/usr/local/etc/rc.d/ipw.sh) always execute after network init (specify in rc.conf). Is there any way to make "ipwcontrol -i ipw0 -f /usr/local/share/ipw-firmware/ipw.fw" command execute before network init. ? Please help. regards reza From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 07:16:26 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 203A216A41F for ; Wed, 28 Dec 2005 07:16:26 +0000 (GMT) (envelope-from V.Ovsyannikov@kr.ru) Received: from ns.kr.ru (ns.kr.ru [84.22.128.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3BC343D46 for ; Wed, 28 Dec 2005 07:16:25 +0000 (GMT) (envelope-from V.Ovsyannikov@kr.ru) Received: from gravis.skala-net.ru (gravis.skala-net.ru [84.22.128.254]) by ns.kr.ru (Postfix) with ESMTP id 708F822E6B for ; Wed, 28 Dec 2005 14:16:22 +0700 (KRAT) Date: Wed, 28 Dec 2005 14:17:12 +0700 From: Vitaliy Ovsyannikov X-Priority: 3 (Normal) Message-ID: <1817720534.20051228141712@kr.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: ng_iface+ng_netflow trouble X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vitaliy Ovsyannikov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 07:16:26 -0000 Hello, freebsd-net. Look at this: I did: # ngctl connect vlan44: netflow: lower out31 # ngctl connect vlan44: netflow: upper iface31 What's was wrong, and I repeat with changes: # ngctl shutdown vlan44: it's ok, node vlan44 is gone and 'ngctl show netflow:' doesn't show any out/iface hooks connected to it. And I'm enter fixed commands (upper hook placed instead of lower hook): # ngctl connect vlan44: netflow: upper out31 # ngctl connect vlan44: netflow: lower iface31 It's executes without any errors and I'm trying to look at the results: # ngctl show netflow: | grep vlan44 iface31 vlan44 ether 00000136 lower Where is out31 hook now? If I change the hooks id from 31 to another unused value, it's does well: # ngctl shutdown vlan44: # ngctl connect vlan44: netflow: upper out33 # ngctl connect vlan44: netflow: lower iface33 # ngctl show netflow: | grep vlan44 iface33 vlan44 ether 00000136 lower out33 vlan44 ether 00000136 upper -- Sincerely, Vitaliy Ovsyannikov JSC Skala, Krasnoyarsk, Russia From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 10:05:17 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 067C116A41F; Wed, 28 Dec 2005 10:05:17 +0000 (GMT) (envelope-from subscriber@osk.com.ua) Received: from gandalf.osk.com.ua (osk.com.ua [195.5.17.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0A8E43D5E; Wed, 28 Dec 2005 10:05:15 +0000 (GMT) (envelope-from subscriber@osk.com.ua) Received: from localhost (localhost [127.0.0.1]) by gandalf.osk.com.ua (Postfix) with ESMTP id CDC6978C1F; Wed, 28 Dec 2005 12:09:11 +0200 (EET) Received: from gandalf.osk.com.ua ([127.0.0.1]) by localhost (gandalf.osk.com.ua [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62474-16; Wed, 28 Dec 2005 12:09:11 +0200 (EET) Received: from OLEG (unknown [192.168.82.111]) by gandalf.osk.com.ua (Postfix) with ESMTP id 0846078C1D; Wed, 28 Dec 2005 12:09:10 +0200 (EET) Date: Wed, 28 Dec 2005 12:02:50 +0200 From: Oleg Tarasov X-Mailer: The Bat! (v3.0.1.33) Professional X-Priority: 3 (Normal) Message-ID: <328779425.20051228120250@osk.com.ua> To: Gleb Smirnoff In-Reply-To: <20051227193148.GP1496@cell.sick.ru> References: <1687545235.20051226134150@osk.com.ua> <1122736554.20051226175631@osk.com.ua> <20051227002927.GH1496@FreeBSD.org> <1945317870.20051227175519@osk.com.ua> <20051227193148.GP1496@cell.sick.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at osk.com.ua Cc: freebsd-net@FreeBSD.org Subject: Re: Router on 6.0-stable fails to route tcp packets due to NAT?? malfunction X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: FreeBSD MailList List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 10:05:17 -0000 Hello, Gleb Smirnoff wrote: > Unfortunately this options will not help in your situation. It affects > only the packets received on the mpd's interface, while you need > to alter outgoing packets. > I have fixed this in mpd CVS, but this isn't included in any release > yet. However, if you are experienced enough with CVS you can grab > and compile sources yourself. Thanks a lot, Gleb. I've downloaded mpd4 and installed it successfully - now everything works quite fine. Thus there were some difficulties - appearance of auth layer and needed libpdel but as a result we have quite perfect result. Thanks for developing my favourite ppp daemon :) -- Best regards, Oleg Tarasov mailto:subscriber@osk.com.ua From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 10:09:19 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53D9716A423 for ; Wed, 28 Dec 2005 10:09:19 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78FB043D5C for ; Wed, 28 Dec 2005 10:09:18 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jBSA9GS0028436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Dec 2005 13:09:16 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jBSA9Fce028435; Wed, 28 Dec 2005 13:09:16 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 28 Dec 2005 13:09:15 +0300 From: Gleb Smirnoff To: Oleg Tarasov Message-ID: <20051228100915.GY1496@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Oleg Tarasov , freebsd-net@FreeBSD.org References: <1687545235.20051226134150@osk.com.ua> <1122736554.20051226175631@osk.com.ua> <20051227002927.GH1496@FreeBSD.org> <1945317870.20051227175519@osk.com.ua> <20051227193148.GP1496@cell.sick.ru> <328779425.20051228120250@osk.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <328779425.20051228120250@osk.com.ua> User-Agent: Mutt/1.5.6i Cc: freebsd-net@FreeBSD.org Subject: Re: Router on 6.0-stable fails to route tcp packets due to NAT?? malfunction X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 10:09:19 -0000 On Wed, Dec 28, 2005 at 12:02:50PM +0200, Oleg Tarasov wrote: O> > Unfortunately this options will not help in your situation. It affects O> > only the packets received on the mpd's interface, while you need O> > to alter outgoing packets. O> O> > I have fixed this in mpd CVS, but this isn't included in any release O> > yet. However, if you are experienced enough with CVS you can grab O> > and compile sources yourself. O> O> Thanks a lot, Gleb. I've downloaded mpd4 and installed it O> successfully - now everything works quite fine. O> O> Thus there were some difficulties - appearance of auth layer and O> needed libpdel but as a result we have quite perfect result. O> O> Thanks for developing my favourite ppp daemon :) Thank you for testing unreleased code! Did ng_tcpmss came into action or mpd alters packets in userland? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 13:09:45 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B38416A420; Wed, 28 Dec 2005 13:09:45 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0B9443D79; Wed, 28 Dec 2005 13:09:35 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 9A4BBB4; Wed, 28 Dec 2005 08:09:56 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 52A0618D3; Wed, 28 Dec 2005 08:09:54 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Erb3b-0001jx-38; Wed, 28 Dec 2005 13:09:31 +0000 Date: Wed, 28 Dec 2005 13:09:31 +0000 From: Brian Candler To: Gleb Smirnoff Message-ID: <20051228130930.GA6633@uk.tiscali.com> References: <1687545235.20051226134150@osk.com.ua> <1122736554.20051226175631@osk.com.ua> <20051227002927.GH1496@FreeBSD.org> <1945317870.20051227175519@osk.com.ua> <20051227193148.GP1496@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051227193148.GP1496@cell.sick.ru> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@FreeBSD.org, Oleg Tarasov Subject: Re: Router on 6.0-stable fails to route tcp packets due to NAT?? malfunction X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 13:09:45 -0000 On Tue, Dec 27, 2005 at 10:31:48PM +0300, Gleb Smirnoff wrote: > O> I have the latest version of ported mpd (3.18_3) installed and tried > O> to insert > O> set iface enable tcpmssfix > O> but no positive result, but I understand that this option should help > O> in this situation. > > Unfortunately this options will not help in your situation. It affects > only the packets received on the mpd's interface, while you need > to alter outgoing packets. > > I have fixed this in mpd CVS, but this isn't included in any release > yet. However, if you are experienced enough with CVS you can grab > and compile sources yourself. BTW, I found a really nice description of this problem (with colourful diagrams and FreeBSD solutions) here: http://renaud.waldura.com/doc/freebsd/pppoe/#pmtu Regards, Brian. From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 14:38:28 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1094B16A41F for ; Wed, 28 Dec 2005 14:38:28 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C31743D6E for ; Wed, 28 Dec 2005 14:38:20 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id EAE19C1 for ; Wed, 28 Dec 2005 09:38:40 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id C39131FC8 for ; Wed, 28 Dec 2005 09:38:40 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErcRV-0001np-B2 for freebsd-net@freebsd.org; Wed, 28 Dec 2005 14:38:17 +0000 Date: Wed, 28 Dec 2005 14:38:17 +0000 From: Brian Candler To: freebsd-net@freebsd.org Message-ID: <20051228143817.GA6898@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 14:38:28 -0000 The IPSEC documentation at http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html is pretty weird. It suggests that you encapsulate your packets in IP-IP (gif) encapsulation and THEN encapsulate that again using IPSEC tunnel mode. e.g. notice where it shows spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; ... ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D ('ipencap' is IP protocol 4, aka RFC 2003 encapsulation). The diagram beneath makes this double-tunnelling explicit. This is a really strange approach which is almost guaranteed not to interoperate with other IPSEC gateways. (It might be useful if you were using etherip encapsulation and attempting to bridge two remote networks, but that's not what it's doing either. In any case, if you're encapsulating with a different protocol then you only need IPSEC transport mode, not tunnel mode) ISTM that this chapter should be rewritten to use IPSEC tunnel mode solely. Do people here generally agree? If so I'll try to find the time to modify it. Regards, Brian. From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 15:04:10 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2832716A41F for ; Wed, 28 Dec 2005 15:04:10 +0000 (GMT) (envelope-from regnauld@moof.catpipe.net) Received: from moof.catpipe.net (moof.catpipe.net [195.249.214.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7284443D62 for ; Wed, 28 Dec 2005 15:04:08 +0000 (GMT) (envelope-from regnauld@moof.catpipe.net) Received: from localhost (localhost [127.0.0.1]) by localhost.catpipe.net (Postfix) with ESMTP id E29811B385; Wed, 28 Dec 2005 16:04:06 +0100 (CET) Received: from moof.catpipe.net ([127.0.0.1]) by localhost (moof.catpipe.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48997-08; Wed, 28 Dec 2005 16:04:04 +0100 (CET) Received: by moof.catpipe.net (Postfix, from userid 1001) id 359EB1B398; Wed, 28 Dec 2005 16:04:04 +0100 (CET) Date: Wed, 28 Dec 2005 16:04:04 +0100 From: Phil Regnauld To: Brian Candler Message-ID: <20051228150404.GA49024@moof.catpipe.net> References: <20051228143817.GA6898@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051228143817.GA6898@uk.tiscali.com> X-Operating-System: FreeBSD 4.8-STABLE i386 Organization: catpipe Systems ApS User-Agent: Mutt/1.5.6i X-Virus-Scanned: amavisd-new at catpipe.net Cc: freebsd-net@freebsd.org Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 15:04:10 -0000 Brian Candler (B.Candler) writes: > The IPSEC documentation at > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html is > pretty weird. It suggests that you encapsulate your packets in IP-IP (gif) > encapsulation and THEN encapsulate that again using IPSEC tunnel mode. > This is a really strange approach which is almost guaranteed not to > interoperate with other IPSEC gateways. It's probably for FreeBSD <-> FreeBSD setups, where it might make sense to have an interface endpoint, rather than the "transparent" IPsec approach -- otherwise it's not possible to route via the remote endpoint, or apply filters at interface level before leaving the gateway. > with a different protocol then you only need IPSEC transport mode, not > tunnel mode) Yes, here using tunnel is indeed odd, it would make more sense of using IPIP or just GRE in transport mode. > ISTM that this chapter should be rewritten to use IPSEC tunnel mode solely. > Do people here generally agree? If so I'll try to find the time to modify > it. Or present both setups. If you do it, I'll contribute and review. Phil From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 15:08:21 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13DC716A41F for ; Wed, 28 Dec 2005 15:08:21 +0000 (GMT) (envelope-from matt@gsicomp.on.ca) Received: from skippyii.compar.com (mail.compar.com [216.208.38.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14E4743D7C for ; Wed, 28 Dec 2005 15:08:14 +0000 (GMT) (envelope-from matt@gsicomp.on.ca) Received: from hermes (CPE00062566c7bb-CM0011e6ede298.cpe.net.cable.rogers.com [70.28.254.189]) by skippyii.compar.com (8.13.1/8.13.1) with ESMTP id jBSF9PaC036331; Wed, 28 Dec 2005 10:09:29 -0500 (EST) (envelope-from matt@gsicomp.on.ca) Message-ID: <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca> From: "Matt Emmerton" To: "Brian Candler" , References: <20051228143817.GA6898@uk.tiscali.com> Date: Wed, 28 Dec 2005 10:08:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Cc: Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 15:08:21 -0000 > The IPSEC documentation at > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html is > pretty weird. It suggests that you encapsulate your packets in IP-IP (gif) > encapsulation and THEN encapsulate that again using IPSEC tunnel mode. > > This is a really strange approach which is almost guaranteed not to > interoperate with other IPSEC gateways. (It might be useful if you were > using etherip encapsulation and attempting to bridge two remote networks, > but that's not what it's doing either. In any case, if you're encapsulating > with a different protocol then you only need IPSEC transport mode, not > tunnel mode) While correct, note the scenario for which the configuration is describing: 14.10.3 The Scenario: Two networks, connected to the Internet, to behave as one. This is something I do all the time to connect retail outlets to the server at the head office. This double-encapsulation ensures that nobody can sniff my packets, which contain sensitive information such as credit card data (which is already encrypted via HTTPS, but you can't be too safe!) > ISTM that this chapter should be rewritten to use IPSEC tunnel mode solely. > Do people here generally agree? If so I'll try to find the time to modify > it. This perhaps would be a good _addition_ to the existing documentation -- it's likely a configuration that many would want to set up, especially to inter-operate with corporate networks (using commercial IPSec solutions) -- or for those who don't need the double-encapsulation. -- Matt Emmerton From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 15:26:53 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A9E716A41F for ; Wed, 28 Dec 2005 15:26:53 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from mallaury.nerim.net (smtp-103-wednesday.noc.nerim.net [62.4.17.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E65543D70 for ; Wed, 28 Dec 2005 15:26:49 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from srvbsdnanssv.interne.kisoft-services.com (kisoft.net1.nerim.net [62.212.107.51]) by mallaury.nerim.net (Postfix) with ESMTP id 55FDD4F3EB; Wed, 28 Dec 2005 16:26:37 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by srvbsdnanssv.interne.kisoft-services.com (Postfix) with ESMTP id BA51AC8B2; Wed, 28 Dec 2005 16:26:44 +0100 (CET) Received: from srvbsdnanssv.interne.kisoft-services.com ([127.0.0.1]) by localhost (srvbsdnanssv.interne.kisoft-services.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68408-10; Wed, 28 Dec 2005 16:26:43 +0100 (CET) Received: by srvbsdnanssv.interne.kisoft-services.com (Postfix, from userid 1001) id 32F76C8AE; Wed, 28 Dec 2005 16:26:43 +0100 (CET) To: Brian Candler From: Eric Masson In-Reply-To: <20051228143817.GA6898@uk.tiscali.com> (Brian Candler's message of "Wed, 28 Dec 2005 14:38:17 +0000") References: <20051228143817.GA6898@uk.tiscali.com> X-Operating-System: FreeBSD 5.4-RELEASE-p2 i386 Date: Wed, 28 Dec 2005 16:26:43 +0100 Message-ID: <86lky5p7ik.fsf@srvbsdnanssv.interne.kisoft-services.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at interne.kisoft-services.com Cc: freebsd-net@freebsd.org Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 15:26:53 -0000 Brian Candler writes: Hi, > The IPSEC documentation at > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html is > pretty weird. It suggests that you encapsulate your packets in IP-IP (gif) > encapsulation and THEN encapsulate that again using IPSEC tunnel mode. Well transport mode is sufficient and imho logical in this setup, that's right. > ISTM that this chapter should be rewritten to use IPSEC tunnel mode solely. > Do people here generally agree ? No. gif/gre tunnels and ipsec transport mode are quite convenient when associated with dynamic routing protocols. Adding a section about pure ipsec tunnels would be a better approach (check handbook cvs history, iirc, ipsec tunnels were described in a previous version) Éric Masson -- Je vous ferez remarquer chers câblés et très très chères câblées qu'un simple message INNOCENT (j'insiste) a engendré près de 10 réponses !!! -+- PC in : Tous coupables, tous. -+- From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 15:31:12 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FD2516A41F for ; Wed, 28 Dec 2005 15:31:12 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2911443D5F for ; Wed, 28 Dec 2005 15:31:09 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 55DA9B5; Wed, 28 Dec 2005 10:31:31 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 0D03F20B1; Wed, 28 Dec 2005 10:31:29 -0500 (EST) Received: from brian by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErdGc-0001qB-KS; Wed, 28 Dec 2005 15:31:06 +0000 Date: Wed, 28 Dec 2005 15:31:06 +0000 From: Brian Candler To: Matt Emmerton Message-ID: <20051228153106.GA7041@uk.tiscali.com> References: <20051228143817.GA6898@uk.tiscali.com> <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 15:31:12 -0000 On Wed, Dec 28, 2005 at 10:08:54AM -0500, Matt Emmerton wrote: > While correct, note the scenario for which the configuration is describing: > > 14.10.3 The Scenario: Two networks, connected to the Internet, to behave as > one. > > This is something I do all the time to connect retail outlets to the server > at the head office. This double-encapsulation ensures that nobody can sniff > my packets, which contain sensitive information such as credit card data > (which is already encrypted via HTTPS, but you can't be too safe!) Well yes, but that's the whole point of IPSEC tunnel mode. The original IP datagram (header+payload) is wrapped in an ESP encrypted packet, a new IP header added (with the tunnel endpoint IPs as source and destination), and the packet is sent. If you sniff it, all you see is the tunnel header and the opaque ESP blob. You can see neither the original data nor the original source and destination IP addresses. There's no point doing GIF tunneling tunneling as well when IPSEC tunnel mode does that already. For someone new to IPSEC it confuses the issue; it adds extra processing overhead; and it reduces the number of bytes of usable payload data in each packet. I can also see a problem where someone implements the first part of this document (the GIF tunnel without IPSEC), finds that their two networks are communicating successfully, and says "great, I have a VPN, I don't need to do any more!" Or they could make a mistake with their IPSEC policy configuration, and believe that they have a secure encrypted VPN, when in fact all they have is GIF encapsulation. > > ISTM that this chapter should be rewritten to use IPSEC tunnel mode > solely. > > Do people here generally agree? If so I'll try to find the time to modify > > it. > > This perhaps would be a good _addition_ to the existing documentation -- > it's likely a configuration that many would want to set up, especially to > inter-operate with corporate networks (using commercial IPSec solutions) -- > or for those who don't need the double-encapsulation. My question is: who *does* need the double-encapsulation? I cannot see any benefit, and I can see good reasons not to do it. I would like to rewrite this document (or see it rewritten) to include: - Gateways with IPSEC tunnel mode and static keys - Gateways with IPSEC tunnel mode and racoon - Gateways with IPSEC tunnel mode, racoon and XAUTH/RADIUS (= Cisco road warrier) - IPSEC Transport mode with racoon - L2TP + IPSEC transport mode (= Windows road warrier) plus descriptions of how to get each of those to interoperate with some other common IPSEC implementations. Those are the most useful modes of IPSEC. Having others like GIF+IPSEC just complicates something which is already far too complicated, and shows a lack of understanding of the IPSEC security model anyway. If FreeBSD supports etherip encapsulation (RFC 3378), and it's possible to combine bridging with etherip and IPSEC transport mode, then that's another mode which would be useful to document (i.e. ethernet bridge over WAN) Also excellent would be "bump in the wire" bridging, where the gateway negotiates transport-mode security on behalf of clients without their being aware of it, but as far as I know only OpenBSD supports that. Regards, Brian. From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 15:55:57 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 640E816A41F for ; Wed, 28 Dec 2005 15:55:57 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id F073443D8E for ; Wed, 28 Dec 2005 15:55:49 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 3451FC1; Wed, 28 Dec 2005 10:56:10 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id EAA1344CC; Wed, 28 Dec 2005 10:56:08 -0500 (EST) Received: from brian by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErdeT-0001s3-Pv; Wed, 28 Dec 2005 15:55:45 +0000 Date: Wed, 28 Dec 2005 15:55:45 +0000 From: Brian Candler To: Eric Masson Message-ID: <20051228155545.GA7166@uk.tiscali.com> References: <20051228143817.GA6898@uk.tiscali.com> <86lky5p7ik.fsf@srvbsdnanssv.interne.kisoft-services.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86lky5p7ik.fsf@srvbsdnanssv.interne.kisoft-services.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 15:55:57 -0000 On Wed, Dec 28, 2005 at 04:26:43PM +0100, Eric Masson wrote: > gif/gre tunnels and ipsec transport mode are quite convenient when > associated with dynamic routing protocols. OK, I'll buy gif + IPSEC transport mode as an option. [Although in that case, perhaps what you want is an external IPSEC tunnel mode implementation which attaches to a 'tun' device. That's yet another category which I hadn't even considered] I still think that gif + IPSEC tunnel mode (as currently documented) is not a good approach, especially if it's the *only* mode of operation to be documented and hence implicitly recommended as the 'right' way to do it. From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 16:05:34 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6802216A41F for ; Wed, 28 Dec 2005 16:05:34 +0000 (GMT) (envelope-from jdkullmann@aliencamel.com) Received: from aliencamel.com (aliencamel.com [69.93.161.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B2E443D58 for ; Wed, 28 Dec 2005 16:05:27 +0000 (GMT) (envelope-from jdkullmann@aliencamel.com) X-Virus-Scanned: by both ClamAV and Kaspersky at http://aliencamel.com/ Received: from [67.81.216.207] (account jdkullmann@aliencamel.com) by aliencamel.com (CommuniGate Pro WebUser 4.2.10) with HTTP id 20075673 for freebsd-net@freebsd.org; Wed, 28 Dec 2005 16:05:10 +0000 From: "JK" To: freebsd-net@freebsd.org X-Mailer: CommuniGate Pro WebUser Interface v.4.2.10 Date: Wed, 28 Dec 2005 12:05:10 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit Subject: 5.4 / 6.0 wi0 and dhcp with closed network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 16:05:34 -0000 I cannot get this to work at startup time on 5.4 On 6.0 I put ifconfig_wi0="ssid mynet DHCP" into /etc/rc.conf and that works. I end up on the closed 'mynet' network via a DHCP address. On 5.4 neither that line nor other combinations in /etc/rc.conf of ifconfig_wi0="DHCP" ifconfig_wi0="ssid mynet" dhclient wi0 work. I _can_ get up on 5.4 by booting and then manually doing ifconfig wi0 ssid mynet dhclient wi0 After dhclient receives the IP etc from the server the machine is up fine. How in the world do I do this in /etc/rc.conf ( or other files ) on 5.4 so it works automatically at startup time? From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 16:06:47 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4D8516A41F for ; Wed, 28 Dec 2005 16:06:47 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AA9D43D78 for ; Wed, 28 Dec 2005 16:06:15 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 6C576AE; Wed, 28 Dec 2005 11:06:26 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 30AA02AD0; Wed, 28 Dec 2005 11:06:25 -0500 (EST) Received: from brian by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErdoP-0001sX-Sp; Wed, 28 Dec 2005 16:06:02 +0000 Date: Wed, 28 Dec 2005 16:06:01 +0000 From: Brian Candler To: Phil Regnauld Message-ID: <20051228160601.GB7166@uk.tiscali.com> References: <20051228143817.GA6898@uk.tiscali.com> <20051228150404.GA49024@moof.catpipe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051228150404.GA49024@moof.catpipe.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 16:06:47 -0000 On Wed, Dec 28, 2005 at 04:04:04PM +0100, Phil Regnauld wrote: > > This is a really strange approach which is almost guaranteed not to > > interoperate with other IPSEC gateways. > > It's probably for FreeBSD <-> FreeBSD setups, where it might make sense > to have an interface endpoint, rather than the "transparent" IPsec > approach -- otherwise it's not possible to route via the remote > endpoint, or apply filters at interface level before leaving the > gateway. If it's done that way purely as a workaround for limitations of the FreeBSD IPSEC architecture then that's OK, but I think it should be explicitly documented as such. Otherwise the rationale is unclear. (Presumably by "transparent" IPSEC you mean that the kernel takes care of IPSEC policy independently of ipfw/pf filtering; you're not talking about a transparent IPSEC gateway such as http://www.thought.net/jason/bridgepaper/node12.html ) It's a shame that this workaround means that you actually have to change the data format on the wire, as this will reduce interoperability. ISTM what you really want is to be able to have IPSEC tunnels each appear as separate interfaces, e.g. ipsec0 or tun0, so that firewall policy can be associated with each one. The old userland IPSEC implementations had this benefit, of course. Are any of these still maintained and usable? If so then perhaps they should also be documented as an alternative. Actually, I did come across a paper which discussed extending the socket API so that application decisions could be made on the basis of the IPSEC attributes by which the data was delivered; ah yes, here it is. http://seclab.cs.ucdavis.edu/papers/314-PHIL.pdf Integrating something like that with ipfw/pf would also give the flexibility to associate packets with their IPSEC flows. But I digress. Regards, Brian. From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 16:15:45 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBEDC16A41F for ; Wed, 28 Dec 2005 16:15:45 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from mallaury.nerim.net (smtp-103-wednesday.noc.nerim.net [62.4.17.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CB1543D55 for ; Wed, 28 Dec 2005 16:15:45 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from srvbsdnanssv.interne.kisoft-services.com (kisoft.net1.nerim.net [62.212.107.51]) by mallaury.nerim.net (Postfix) with ESMTP id 376DA4F3DB; Wed, 28 Dec 2005 17:15:34 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by srvbsdnanssv.interne.kisoft-services.com (Postfix) with ESMTP id 9BA35C8B0; Wed, 28 Dec 2005 17:15:42 +0100 (CET) Received: from srvbsdnanssv.interne.kisoft-services.com ([127.0.0.1]) by localhost (srvbsdnanssv.interne.kisoft-services.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68863-03; Wed, 28 Dec 2005 17:15:39 +0100 (CET) Received: by srvbsdnanssv.interne.kisoft-services.com (Postfix, from userid 1001) id B50EFC8BA; Wed, 28 Dec 2005 17:15:39 +0100 (CET) To: Brian Candler From: Eric Masson In-Reply-To: <20051228155545.GA7166@uk.tiscali.com> (Brian Candler's message of "Wed, 28 Dec 2005 15:55:45 +0000") References: <20051228143817.GA6898@uk.tiscali.com> <86lky5p7ik.fsf@srvbsdnanssv.interne.kisoft-services.com> <20051228155545.GA7166@uk.tiscali.com> X-Operating-System: FreeBSD 5.4-RELEASE-p2 i386 Date: Wed, 28 Dec 2005 17:15:39 +0100 Message-ID: <86d5jhp590.fsf@srvbsdnanssv.interne.kisoft-services.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at interne.kisoft-services.com Cc: freebsd-net@freebsd.org Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 16:15:46 -0000 Brian Candler writes: > OK, I'll buy gif + IPSEC transport mode as an option. [Although in that > case, perhaps what you want is an external IPSEC tunnel mode implementation > which attaches to a 'tun' device. That's yet another category which I hadn't > even considered] Any url describing this setup please ? > I still think that gif + IPSEC tunnel mode (as currently documented) is not > a good approach, especially if it's the *only* mode of operation to be > documented and hence implicitly recommended as the 'right' way to do it. Well, ipsec section of the handbook is probably not the best one, I'd like to see it extended with the sections you talked about in this thread. Maybe it's time to submit patches... -- >pourkoi faire ca c koi le but? je vois pas l interet c un forum libre >ou tt le monde px s exprimer c pas mtnt kil faut reagir c ds les posts Au secours, mon ROT-13 ne marche plus :-(((( -+- PC in : Neuneu decode à plein tube -+- From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 16:20:52 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7BDF16A422 for ; Wed, 28 Dec 2005 16:20:52 +0000 (GMT) (envelope-from gaylord@dirtcheapemail.com) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C38843D6E for ; Wed, 28 Dec 2005 16:20:52 +0000 (GMT) (envelope-from gaylord@dirtcheapemail.com) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id 08D5BD2E9D9 for ; Wed, 28 Dec 2005 11:20:51 -0500 (EST) Received: from web2.messagingengine.com ([10.202.2.211]) by frontend1.internal (MEProxy); Wed, 28 Dec 2005 11:20:51 -0500 Received: by web2.messagingengine.com (Postfix, from userid 99) id 8F5275AC5; Wed, 28 Dec 2005 11:20:45 -0500 (EST) Message-Id: <1135786845.21398.250667837@webmail.messagingengine.com> X-Sasl-Enc: P+apgRDSfoN0XR13bOAY4RM+6ukuQ5CvqRkUvgzOiF/y 1135786845 From: "Clark Gaylord" To: freebsd-net@freebsd.org Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.5 (F2.73; T1.15; A1.64; B3.05; Q3.03) References: <20051228143817.GA6898@uk.tiscali.com> <20051228150404.GA49024@moof.catpipe.net> In-Reply-To: <20051228150404.GA49024@moof.catpipe.net> Date: Wed, 28 Dec 2005 11:20:45 -0500 Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 16:20:53 -0000 On Wed, 28 Dec 2005 16:04:04 +0100, "Phil Regnauld" said: > Yes, here using tunnel is indeed odd, it would make more sense > of using IPIP or just GRE in transport mode. I have often used GRE+IPsecTransport -- this allows routing protocols, link state (if you have GRE keepalives), etc, to function correctly, and I think it is easier to see what is going on than the "transparent" IPsec tunnel approach. Haven't done it with FreeBSD, though. --ckg -- Clark Gaylord Blacksburg, VA USA gaylord@dirtcheapemail.com From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 16:29:29 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDE9816A41F for ; Wed, 28 Dec 2005 16:29:29 +0000 (GMT) (envelope-from gaylord@dirtcheapemail.com) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2179C43D72 for ; Wed, 28 Dec 2005 16:29:29 +0000 (GMT) (envelope-from gaylord@dirtcheapemail.com) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id AA268D2E7D3 for ; Wed, 28 Dec 2005 11:29:26 -0500 (EST) Received: from web2.messagingengine.com ([10.202.2.211]) by frontend1.internal (MEProxy); Wed, 28 Dec 2005 11:29:26 -0500 Received: by web2.messagingengine.com (Postfix, from userid 99) id 21C505FA6; Wed, 28 Dec 2005 11:29:21 -0500 (EST) Message-Id: <1135787361.22425.250668026@webmail.messagingengine.com> X-Sasl-Enc: IFY//a731EILsqA5PiZRyma1X0g8mR1gS8icHqG8LmSr 1135787361 From: "Clark Gaylord" To: freebsd-net@freebsd.org Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.5 (F2.73; T1.15; A1.64; B3.05; Q3.03) References: <20051228143817.GA6898@uk.tiscali.com> <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca> In-Reply-To: <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca> Date: Wed, 28 Dec 2005 11:29:21 -0500 Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 16:29:29 -0000 On Wed, 28 Dec 2005 10:08:54 -0500, "Matt Emmerton" said: > (which is already encrypted via HTTPS, but you can't be too safe!) Yes and no. There are substantial support and performance costs every time you encrypt. You can figure that encryption will cost you about 1/3 of your bandwidth every time you do it (different protocols vary, but not a bad rule of thumb). So, double encryption gives you 44% throughput, where single encryption gives you 67% -- triple it and you are down to 30%, etc. The "encrypt at every layer possible" approach is only good if you have an infinite budget (or you are the WAN service provider who gets to receive the revenue from your infinite budget), infinite CPU, and infinite staff. That being said, it is ok to have some "belt and suspenders" designs, but usually I find that solving a problem once allows me to a) do it better and b) solve more problems. Labyrinthine solutions are inherently insecure. --ckg -- Clark Gaylord Blacksburg, VA USA gaylord@dirtcheapemail.com From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 16:43:53 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9A9216A41F for ; Wed, 28 Dec 2005 16:43:53 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from corwin.easynet.fr (smarthost171.mail.easynet.fr [212.180.1.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2789C43D5D for ; Wed, 28 Dec 2005 16:43:52 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from easyconnect2121135-233.clients.easynet.fr ([212.11.35.233] helo=smtp.zeninc.net) by corwin.easynet.fr with esmtp (Exim 4.50) id 1EreOp-0001TX-BV; Wed, 28 Dec 2005 17:43:39 +0100 Received: by smtp.zeninc.net (smtpd, from userid 1000) id 735FE3F17; Wed, 28 Dec 2005 17:43:39 +0100 (CET) Date: Wed, 28 Dec 2005 17:43:39 +0100 From: VANHULLEBUS Yvan To: Brian Candler Message-ID: <20051228164339.GB3875@zen.inc> References: <20051228143817.GA6898@uk.tiscali.com> <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca> <20051228153106.GA7041@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051228153106.GA7041@uk.tiscali.com> User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-net@freebsd.org Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 16:43:54 -0000 Hi all. Coming a bit late in the discussion, but I guess I can provide some infos.... On Wed, Dec 28, 2005 at 03:31:06PM +0000, Brian Candler wrote: [....] > I would like to rewrite this document (or see it rewritten) to include: > > - Gateways with IPSEC tunnel mode and static keys Well, this can be interesting, but is considered as obsolete / not so secure by most people/vendors/implementors ! > - Gateways with IPSEC tunnel mode and racoon I can easily write this part if you want. And if someone else does that part (and some other ones involving racoon), please notice that port security/racoon is now obsolete and have been replaced by port security/ipsec-tools ! And I would add "roadwarriors with IPSec tunnel mode and racoon". > - Gateways with IPSEC tunnel mode, racoon and XAUTH/RADIUS (= Cisco road warrier) > - IPSEC Transport mode with racoon > - L2TP + IPSEC transport mode (= Windows road warrier) Did someone tried such a setup ? is there a L2TPD daemon running on FreeBSD which could be used for that ? Note also that, for now, this won't work easily, as it will require dynamic SP entries (roadwarriors....), but I think racoon currently can't deal with dynamic policies when ports specified (I'll check that). > plus descriptions of how to get each of those to interoperate with some > other common IPSEC implementations. I can provide lots of informations about that ! And the first thing to do would be to explain the net.key.preferred_oldsa's role, and to tell everybody to set it to 0 (it is set to 1 by default). [...] > Also excellent would be "bump in the wire" bridging, where the gateway > negotiates transport-mode security on behalf of clients without their being > aware of it, but as far as I know only OpenBSD supports that. What is the benefit of transport mode for that, instead of just using an IPSec tunnel between the gates ??? Yvan. -- NETASQ - Secure Internet Connectivity http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 17:04:43 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 833A716A41F for ; Wed, 28 Dec 2005 17:04:43 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1A1643D45 for ; Wed, 28 Dec 2005 17:04:42 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from srvbsdnanssv.interne.kisoft-services.com (kisoft.net1.nerim.net [62.212.107.51]) by kraid.nerim.net (Postfix) with ESMTP id 34C3F40F56; Wed, 28 Dec 2005 18:04:39 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by srvbsdnanssv.interne.kisoft-services.com (Postfix) with ESMTP id 9BDF7C8B8; Wed, 28 Dec 2005 18:04:38 +0100 (CET) Received: from srvbsdnanssv.interne.kisoft-services.com ([127.0.0.1]) by localhost (srvbsdnanssv.interne.kisoft-services.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68996-03; Wed, 28 Dec 2005 18:04:37 +0100 (CET) Received: by srvbsdnanssv.interne.kisoft-services.com (Postfix, from userid 1001) id D38EBC8B7; Wed, 28 Dec 2005 18:04:37 +0100 (CET) To: VANHULLEBUS Yvan From: Eric Masson In-Reply-To: <20051228164339.GB3875@zen.inc> (VANHULLEBUS Yvan's message of "Wed, 28 Dec 2005 17:43:39 +0100") References: <20051228143817.GA6898@uk.tiscali.com> <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca> <20051228153106.GA7041@uk.tiscali.com> <20051228164339.GB3875@zen.inc> X-Operating-System: FreeBSD 5.4-RELEASE-p2 i386 Date: Wed, 28 Dec 2005 18:04:37 +0100 Message-ID: <868xu5p2ze.fsf@srvbsdnanssv.interne.kisoft-services.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at interne.kisoft-services.com Cc: freebsd-net@freebsd.org, Brian Candler Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 17:04:43 -0000 VANHULLEBUS Yvan writes: Hi Yvan, > Did someone tried such a setup ? I plan to do so. Just have to find ios images that support l2tp and ipsec for my 1601R or 2611 and bigger flash modules (I've been given them two weeks ago, hardware upgrade is the easy part, for software, hope cisco will permit hobbyist licences one of these days) > is there a L2TPD daemon running on FreeBSD which could be used for > that ? ports/net/sl2tps Éric -- AB : (...) et encore on semble échapper aux betas :-, LF : bah peut-être qu'ils en font plus ;-) GG : Ils auraient embauché des types de Microsoft ? -+- GG in Guide du Macounet Pervers : Bah oui, gros béta ! -+- From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 18:50:40 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6016C16A41F for ; Wed, 28 Dec 2005 18:50:40 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EE9143D5E for ; Wed, 28 Dec 2005 18:50:39 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 28 Dec 2005 10:50:39 -0800 X-IronPort-Anti-Spam-Filtered: true Message-ID: <43B2DE7E.5080707@elischer.org> Date: Wed, 28 Dec 2005 10:50:38 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Candler References: <20051228143817.GA6898@uk.tiscali.com> <86lky5p7ik.fsf@srvbsdnanssv.interne.kisoft-services.com> <20051228155545.GA7166@uk.tiscali.com> In-Reply-To: <20051228155545.GA7166@uk.tiscali.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 18:50:40 -0000 Brian Candler wrote: >On Wed, Dec 28, 2005 at 04:26:43PM +0100, Eric Masson wrote: > > >>gif/gre tunnels and ipsec transport mode are quite convenient when >>associated with dynamic routing protocols. >> >> > >OK, I'll buy gif + IPSEC transport mode as an option. [Although in that >case, perhaps what you want is an external IPSEC tunnel mode implementation >which attaches to a 'tun' device. That's yet another category which I hadn't >even considered] > > I use ppp (mpd) over UDP over ipsec transport mode. That gives you a "ng0" interface for the tunnel. (netgraph pseudo interface) >I still think that gif + IPSEC tunnel mode (as currently documented) is not >a good approach, especially if it's the *only* mode of operation to be >documented and hence implicitly recommended as the 'right' way to do it. >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 19:07:25 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93AE616A41F for ; Wed, 28 Dec 2005 19:07:25 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC7B343D67 for ; Wed, 28 Dec 2005 19:07:24 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id B6C23C1; Wed, 28 Dec 2005 14:07:45 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 7C43B27EA; Wed, 28 Dec 2005 14:07:44 -0500 (EST) Received: from brian by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ergdt-00021M-DY; Wed, 28 Dec 2005 19:07:21 +0000 Date: Wed, 28 Dec 2005 19:07:21 +0000 From: Brian Candler To: Eric Masson Message-ID: <20051228190721.GB7695@uk.tiscali.com> References: <20051228143817.GA6898@uk.tiscali.com> <86lky5p7ik.fsf@srvbsdnanssv.interne.kisoft-services.com> <20051228155545.GA7166@uk.tiscali.com> <86d5jhp590.fsf@srvbsdnanssv.interne.kisoft-services.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86d5jhp590.fsf@srvbsdnanssv.interne.kisoft-services.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 19:07:25 -0000 On Wed, Dec 28, 2005 at 05:15:39PM +0100, Eric Masson wrote: > Brian Candler writes: > > > OK, I'll buy gif + IPSEC transport mode as an option. [Although in that > > case, perhaps what you want is an external IPSEC tunnel mode implementation > > which attaches to a 'tun' device. That's yet another category which I hadn't > > even considered] > > Any url describing this setup please ? I don't know definitively. security/vpnc works fine for me as a client for talking to a Cisco VPN concentrator. I think that's IPSEC tunnel mode + PSK + XAUTH (which can also assign an IP address and insert routes into your forwarding table) There's net/pipsecd in ports. Its version is 19991014. I have no idea if it still works. I know of non-IPSEC solutions using tun (OpenVPN, TINC). I also know of userland IPSEC solutions which I don't think run under FreeBSD (FreeS/WAN, OpenS/WAN). All a bit of a nightmare really. Documentation would be good :-) > > I still think that gif + IPSEC tunnel mode (as currently documented) is not > > a good approach, especially if it's the *only* mode of operation to be > > documented and hence implicitly recommended as the 'right' way to do it. > > Well, ipsec section of the handbook is probably not the best one, I'd > like to see it extended with the sections you talked about in this > thread. Maybe it's time to submit patches... Sure. I first just wanted to check that there wasn't something I was missing. Regards, Brian. From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 19:12:42 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C373716A41F for ; Wed, 28 Dec 2005 19:12:42 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 601CA43D49 for ; Wed, 28 Dec 2005 19:12:42 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id C6CFAB4; Wed, 28 Dec 2005 14:13:03 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 7FB7939C1; Wed, 28 Dec 2005 14:13:01 -0500 (EST) Received: from brian by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ergj0-00021i-6m; Wed, 28 Dec 2005 19:12:38 +0000 Date: Wed, 28 Dec 2005 19:12:38 +0000 From: Brian Candler To: VANHULLEBUS Yvan Message-ID: <20051228191238.GC7695@uk.tiscali.com> References: <20051228143817.GA6898@uk.tiscali.com> <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca> <20051228153106.GA7041@uk.tiscali.com> <20051228164339.GB3875@zen.inc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051228164339.GB3875@zen.inc> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 19:12:42 -0000 On Wed, Dec 28, 2005 at 05:43:39PM +0100, VANHULLEBUS Yvan wrote: > > Also excellent would be "bump in the wire" bridging, where the gateway > > negotiates transport-mode security on behalf of clients without their being > > aware of it, but as far as I know only OpenBSD supports that. > > What is the benefit of transport mode for that, instead of just using > an IPSec tunnel between the gates ??? "Opportunistic" encryption and gradual deployment. http://www.thought.net/jason/bridgepaper/node9.html (an interesting paper, read through to at least "Transparent Policy Enforcement") One use would be if you decided to roll out transport mode IPSEC across your network; you could put all the legacy hosts behind such a gateway as a transition measure until you had managed to upgrade them. Regards, Brian. From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 20:04:59 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F21116A41F for ; Wed, 28 Dec 2005 20:04:59 +0000 (GMT) (envelope-from jdkullmann@aliencamel.com) Received: from aliencamel.com (aliencamel.com [69.93.161.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B5F143D55 for ; Wed, 28 Dec 2005 20:04:58 +0000 (GMT) (envelope-from jdkullmann@aliencamel.com) X-Virus-Scanned: by both ClamAV and Kaspersky at http://aliencamel.com/ Received: from [67.81.216.207] (account jdkullmann@aliencamel.com) by aliencamel.com (CommuniGate Pro WebUser 4.2.10) with HTTP id 20083515 for freebsd-net@freebsd.org; Wed, 28 Dec 2005 20:04:57 +0000 From: "JK" To: freebsd-net@freebsd.org X-Mailer: CommuniGate Pro WebUser Interface v.4.2.10 Date: Wed, 28 Dec 2005 16:04:57 -0400 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit Subject: Re: 5.4 / 6.0 wi0 and dhcp with closed network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 20:04:59 -0000 On Wed, 28 Dec 2005 12:05:10 -0400 "JK" wrote: > I cannot get this to work at startup time on 5.4 > > On 6.0 I put ifconfig_wi0="ssid mynet DHCP" into /etc/rc.conf and >that works. I end up on the closed 'mynet' network via a DHCP >address. > > On 5.4 neither that line nor other combinations in /etc/rc.conf of > > ifconfig_wi0="DHCP" > ifconfig_wi0="ssid mynet" > dhclient wi0 > > work. I _can_ get up on 5.4 by booting and then manually doing > > ifconfig wi0 ssid mynet > dhclient wi0 > > After dhclient receives the IP etc from the server the machine is up >fine. > > How in the world do I do this in /etc/rc.conf ( or other files ) on >5.4 so it works automatically at startup time? > _____________________________________ Following myself up, the only way I could get this to work in 5.4 at startup time was to create a /etc/start_if.wi0 that contained ifconfig wi0 ssid mynet dhclient wi0 and not put any ifconfig_XX commands into my /etc/rc.conf That seems pretty cheesey to me but it works. If anyone else has a cleaner way I'd love to know what it is. From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 06:50:49 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C24D716A41F for ; Thu, 29 Dec 2005 06:50:49 +0000 (GMT) (envelope-from llp@iteranet.com) Received: from eva.iteranet.ru (eva.iteranet.ru [212.74.231.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDD5743D48 for ; Thu, 29 Dec 2005 06:50:48 +0000 (GMT) (envelope-from llp@iteranet.com) Received: from [10.1.41.116] ([10.1.44.45]) by eva.iteranet.ru (8.13.1/8.13.1) with ESMTP id jBT6ofA9025431; Thu, 29 Dec 2005 09:50:41 +0300 (MSK) (envelope-from llp@iteranet.com) Message-ID: <43B38747.1060906@iteranet.com> Date: Thu, 29 Dec 2005 09:50:47 +0300 From: Alexey Popov User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050419) X-Accept-Language: en-us, en MIME-Version: 1.0 To: VANHULLEBUS Yvan References: <20051228143817.GA6898@uk.tiscali.com> <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca> <20051228153106.GA7041@uk.tiscali.com> <20051228164339.GB3875@zen.inc> In-Reply-To: <20051228164339.GB3875@zen.inc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (eva.iteranet.ru [212.74.231.163]); Thu, 29 Dec 2005 09:50:42 +0300 (MSK) X-Virus-Scanned: ClamAV 0.87.1/1219/Thu Dec 29 01:57:59 2005 on eva.iteranet.ru X-Virus-Status: Clean Cc: freebsd-net@freebsd.org, Brian Candler Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2005 06:50:49 -0000 Hi. VANHULLEBUS Yvan wrote: >>- L2TP + IPSEC transport mode (= Windows road warrier) > Did someone tried such a setup ? > is there a L2TPD daemon running on FreeBSD which could be used for > that ? I'm successfully using security/racoon and net/sl2tps with Windows XP/2003 L2TP clients. I've tried pre-shared key as well as X.509 certificates auth. > Note also that, for now, this won't work easily, as it will require > dynamic SP entries (roadwarriors....), but I think racoon currently > can't deal with dynamic policies when ports specified (I'll check > that). racoon has passive_mode option. When it is enabled, racoon can create SPD entries for road warriors. If we would also have NAT-T support, FreeBSD would be the best choice of VPN concentrator. With best regards, Alexey Popov From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 10:19:23 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3551816A41F for ; Thu, 29 Dec 2005 10:19:23 +0000 (GMT) (envelope-from boisan@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89BED43D5D for ; Thu, 29 Dec 2005 10:19:22 +0000 (GMT) (envelope-from boisan@gmail.com) Received: by nproxy.gmail.com with SMTP id o60so93447nfa for ; Thu, 29 Dec 2005 02:19:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=d1M1kZTLY1NpOXqa/q3eKSv1cDI6bXE5EcYYB4vre8f4V093oLynfERjyzJP9IExo4a4GkYZVQ/S1dXpnZo0sCrBzAkX/paWEpVDY7XoPjky1WP6QhpPCvaf+g+8fvAE5sG+2/FxPrOlEHGRlvyeNi7yRMQwDrCNq1kq10L2TPs= Received: by 10.48.254.13 with SMTP id b13mr351983nfi; Thu, 29 Dec 2005 02:19:21 -0800 (PST) Received: by 10.49.41.9 with HTTP; Thu, 29 Dec 2005 02:19:21 -0800 (PST) Message-ID: Date: Thu, 29 Dec 2005 11:19:21 +0100 From: Angel Blazquez To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: nfs server overload (nfsd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2005 10:19:23 -0000 Hello, We are expecting incredible overload in a NFS server. A top shows nfsd consuming most of the CPU: PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMA= ND 6000 root -8 0 1204K 660K biord 1 124:15 27.88% 27.88% nfsd 6002 root 4 0 1204K 660K *Giant 0 124:18 17.58% 17.58% nfsd 6006 root 4 0 1204K 660K *Giant 0 123:38 10.21% 10.21% nfsd 6005 root 4 0 1204K 660K *Giant 0 123:36 7.47% 7.47% nfsd 6003 root 4 0 1204K 660K *Giant 0 123:08 4.15% 4.15% nfsd 6001 root 4 0 1204K 660K *Giant 0 123:16 2.83% 2.83% nfsd Memory looks fine: Mem: 27M Active, 910M Inact, 136M Wired, 51M Cache, 112M Buf, 1828K Free Swap: 2048M Total, 72K Used, 2048M Free Typing in the nfs server (console/ssh) becomes terrible, the server does not reply well. We are running this nfs server in FreeBSD 5.3-RELEASE-p23 on a Compaq Proliant server with a Compaq Smart Array 5300 that comunicates with a array of disks: /dev/da0s1d 164G 124G 27G 82% /data0 /dev/da1s1d 131G 80G 41G 66% /data1 We have /data0 and /data1 exported: /data0 -maproot=3Droot -alldirs -network 192.168.62.0 -mask 255.255.255.0 /data1 -maproot=3Droot -alldirs -network 192.168.62.0 -mask 255.255.255.0 so a couple of incoming SMTP servers we have can deliver e-mail to those filesystems. We are running exim 4.60.0 in those other servers, 4.10-RELEASE-p5 in one of them, and FreeBSD 6.0-RELEASE #0 in the other one. If we stop exim delivering e-mail, nfs server does well, the cpu gets free, and the nfs server works fine (replies to user interaction, etc). FreeBSD 6.0 sysctl output (nfs related): vfs.nfs4.access_cache_timeout: 60 vfs.nfs4.nfsv3_commit_on_close: 0 vfs.nfs.downdelayinitial: 12 vfs.nfs.downdelayinterval: 30 vfs.nfs.realign_test: 1294030 vfs.nfs.realign_count: 0 vfs.nfs.bufpackets: 4 vfs.nfs.reconnects: 2 vfs.nfs.iodmaxidle: 120 vfs.nfs.iodmin: 4 vfs.nfs.iodmax: 20 vfs.nfs.defect: 0 vfs.nfs.nfs_ip_paranoia: 1 vfs.nfs.diskless_valid: 0 vfs.nfs.diskless_rootpath: vfs.nfs.access_cache_timeout: 2 vfs.nfs.nfsv3_commit_on_close: 0 vfs.nfs.clean_pages_on_close: 1 vfs.nfs.nfs_directio_enable: 0 vfs.nfs.nfs_directio_allow_mmap: 1 vfs.nfsrv.nfs_privport: 0 vfs.nfsrv.async: 0 vfs.nfsrv.commit_blks: 0 vfs.nfsrv.commit_miss: 0 vfs.nfsrv.realign_test: 0 vfs.nfsrv.realign_count: 0 vfs.nfsrv.gatherdelay: 10000 vfs.nfsrv.gatherdelay_v3: 0 FreeBSD 4.10 sysctl output (nfs related): vfs.nfs.nfs_privport: 0 vfs.nfs.async: 0 vfs.nfs.commit_blks: 0 vfs.nfs.commit_miss: 0 vfs.nfs.realign_test: 84602323 vfs.nfs.realign_count: 99713 vfs.nfs.bufpackets: 4 vfs.nfs.gatherdelay: 10000 vfs.nfs.gatherdelay_v3: 0 vfs.nfs.defect: 0 vfs.nfs.nfs_ip_paranoia: 1 vfs.nfs.diskless_valid: 0 vfs.nfs.diskless_rootpath: vfs.nfs.diskless_swappath: vfs.nfs.access_cache_timeout: 2 vfs.nfs.nfsv3_commit_on_close: 0 This couple of servers mounts the filesystems with this options: 192.168.62.54:/data1 /mail nfs =20 rw,nfsv3,intr,dumbtimer,rdirplus,nosuid,nodev 0 0 192.168.62.54:/data0 /data0 nfs =20 rw,nfsv3,intr,dumbtimer,rdirplus,nosuid,nodev 0 0 On the server, sysctl nfs related output looks like this: vfs.nfs.downdelayinitial: 12 vfs.nfs.downdelayinterval: 30 vfs.nfs.realign_test: 2694 vfs.nfs.realign_count: 0 vfs.nfs.bufpackets: 4 vfs.nfs.reconnects: 2 vfs.nfs.iodmaxidle: 120 vfs.nfs.iodmin: 4 vfs.nfs.iodmax: 20 vfs.nfs.defect: 0 vfs.nfs.nfs_ip_paranoia: 1 vfs.nfs.diskless_valid: 0 vfs.nfs.diskless_rootpath: vfs.nfs.access_cache_timeout: 2 vfs.nfs.nfsv3_commit_on_close: 0 vfs.nfs4.access_cache_timeout: 60 vfs.nfs4.nfsv3_commit_on_close: 0 vfs.nfsrv.nfs_privport: 0 vfs.nfsrv.async: 1 vfs.nfsrv.commit_blks: 579238 vfs.nfsrv.commit_miss: 413059 vfs.nfsrv.realign_test: 88269083 vfs.nfsrv.realign_count: 11961 vfs.nfsrv.gatherdelay: 10000 vfs.nfsrv.gatherdelay_v3: 0 debug.hashstat.nfsnode: 65536 5 1 0 Thanks in advance, Best regards, Angel Blazquez From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 10:20:08 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90E9E16A428 for ; Thu, 29 Dec 2005 10:20:08 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id B130543D46 for ; Thu, 29 Dec 2005 10:20:03 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from srvbsdnanssv.interne.kisoft-services.com (kisoft.net1.nerim.net [62.212.107.51]) by kraid.nerim.net (Postfix) with ESMTP id F17B740FA9; Thu, 29 Dec 2005 11:20:00 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by srvbsdnanssv.interne.kisoft-services.com (Postfix) with ESMTP id D786AC8D7; Thu, 29 Dec 2005 11:19:59 +0100 (CET) Received: from srvbsdnanssv.interne.kisoft-services.com ([127.0.0.1]) by localhost (srvbsdnanssv.interne.kisoft-services.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38958-01; Thu, 29 Dec 2005 11:19:56 +0100 (CET) Received: by srvbsdnanssv.interne.kisoft-services.com (Postfix, from userid 1001) id D509BC8D2; Thu, 29 Dec 2005 11:19:56 +0100 (CET) To: Brian Candler From: Eric Masson In-Reply-To: <20051228155545.GA7166@uk.tiscali.com> (Brian Candler's message of "Wed, 28 Dec 2005 15:55:45 +0000") References: <20051228143817.GA6898@uk.tiscali.com> <86lky5p7ik.fsf@srvbsdnanssv.interne.kisoft-services.com> <20051228155545.GA7166@uk.tiscali.com> X-Operating-System: FreeBSD 5.4-RELEASE-p2 i386 Date: Thu, 29 Dec 2005 11:19:56 +0100 Message-ID: <8664p88asz.fsf@srvbsdnanssv.interne.kisoft-services.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at interne.kisoft-services.com Cc: freebsd-net@freebsd.org Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2005 10:20:08 -0000 Brian Candler writes: Hi, > OK, I'll buy gif + IPSEC transport mode as an option. Seems there's a rfc about this kind of setup : http://rfc.net/rfc3884.html -- Juste un truc, ca te ferait mal au cerveau de lire les messages auxquels tu reponds ? -+-RMD in : - Neuneu apprend à lire -+- From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 10:27:48 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6AB716A41F for ; Thu, 29 Dec 2005 10:27:48 +0000 (GMT) (envelope-from gaylord@dirtcheapemail.com) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44D5843D46 for ; Thu, 29 Dec 2005 10:27:48 +0000 (GMT) (envelope-from gaylord@dirtcheapemail.com) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id 11858D2E2F3; Thu, 29 Dec 2005 05:27:47 -0500 (EST) Received: from web3.messagingengine.com ([10.202.2.212]) by frontend1.internal (MEProxy); Thu, 29 Dec 2005 05:27:47 -0500 Received: by web3.messagingengine.com (Postfix, from userid 99) id 4AC9F2751; Thu, 29 Dec 2005 05:27:47 -0500 (EST) Message-Id: <1135852067.25722.250713284@webmail.messagingengine.com> X-Sasl-Enc: MZt0utBIVbXj/HftBRXb6dRB5fxNtuWfRSdXgp7fbLSU 1135852067 From: "Clark Gaylord" To: "Alexey Popov" , "VANHULLEBUS Yvan" Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.5 (F2.73; T1.15; A1.64; B3.05; Q3.03) References: <20051228143817.GA6898@uk.tiscali.com> <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca> <20051228153106.GA7041@uk.tiscali.com> <20051228164339.GB3875@zen.inc> <43B38747.1060906@iteranet.com> In-Reply-To: <43B38747.1060906@iteranet.com> Date: Thu, 29 Dec 2005 05:27:47 -0500 Cc: freebsd-net@freebsd.org, Brian Candler Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2005 10:27:48 -0000 On Thu, 29 Dec 2005 09:50:47 +0300, "Alexey Popov" said: > If we would also have NAT-T support, FreeBSD would be the best choice > of VPN concentrator. Yeah, what is the story with that anyway? Is anyone working on it? Is there hope? --ckg -- Clark Gaylord Blacksburg, VA USA gaylord@dirtcheapemail.com From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 10:51:00 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA3B716A41F for ; Thu, 29 Dec 2005 10:51:00 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from mallaury.nerim.net (smtp-104-thursday.noc.nerim.net [62.4.17.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9835A43D62 for ; Thu, 29 Dec 2005 10:50:52 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from srvbsdnanssv.interne.kisoft-services.com (kisoft.net1.nerim.net [62.212.107.51]) by mallaury.nerim.net (Postfix) with ESMTP id B642C4FB1D; Thu, 29 Dec 2005 11:50:41 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by srvbsdnanssv.interne.kisoft-services.com (Postfix) with ESMTP id BDAB0C8D7; Thu, 29 Dec 2005 11:50:46 +0100 (CET) Received: from srvbsdnanssv.interne.kisoft-services.com ([127.0.0.1]) by localhost (srvbsdnanssv.interne.kisoft-services.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38958-06; Thu, 29 Dec 2005 11:50:45 +0100 (CET) Received: by srvbsdnanssv.interne.kisoft-services.com (Postfix, from userid 1001) id 55F5BC8D2; Thu, 29 Dec 2005 11:50:45 +0100 (CET) To: Brian Candler From: Eric Masson In-Reply-To: <20051228190721.GB7695@uk.tiscali.com> (Brian Candler's message of "Wed, 28 Dec 2005 19:07:21 +0000") References: <20051228143817.GA6898@uk.tiscali.com> <86lky5p7ik.fsf@srvbsdnanssv.interne.kisoft-services.com> <20051228155545.GA7166@uk.tiscali.com> <86d5jhp590.fsf@srvbsdnanssv.interne.kisoft-services.com> <20051228190721.GB7695@uk.tiscali.com> X-Operating-System: FreeBSD 5.4-RELEASE-p2 i386 Date: Thu, 29 Dec 2005 11:50:45 +0100 Message-ID: <861wzw89dm.fsf@srvbsdnanssv.interne.kisoft-services.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at interne.kisoft-services.com Cc: freebsd-net@freebsd.org Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2005 10:51:01 -0000 Brian Candler writes: Hi, > security/vpnc works fine for me as a client for talking to a Cisco VPN > concentrator. I think that's IPSEC tunnel mode + PSK + XAUTH (which can also > assign an IP address and insert routes into your forwarding table) Ok, you just need a vpn3000 or other equipment that can act like vpn3000 as remote side. Emmanuel Dreyfus wrote a nice paper about building a vpn concentrator that could act as a server for the cisco vpn client : http://www.netbsd.org/Documentation/network/ipsec/rasvpn.html Iirc, the same could be done on FreeBSD once NAT-T support is merged in the main tree. > There's net/pipsecd in ports. Its version is 19991014. I have no idea if it > still works. Interesting, it seems to be a userland implementation of tunnel mode ipsec tunnel, development has stalled, and dynamic keying is not supported. > I know of non-IPSEC solutions using tun (OpenVPN, TINC). Don't forget SSLTunnel from HSC's Alain Thivillon (ppp over ssl), quite easy to setup net/ssltunnel-* and useful when http/https is the only possibility to reach the outside. > All a bit of a nightmare really. Documentation would be good :-) Yes, sure. Every setup you talked about is documented somewhere on the internet, but a synthesis in the handbook would be really useful. Vpn over ipsec section could be extended to present ipsec based solutions you talked about in this thread. I'd then see two more sections covering ssl vpns and host to host ipsec transport mode (not necessarily in this order) Regards Éric -- tenir à bout de bras un câble ethernet qui traverse une salle de restau pour pas qu'il tombe dans les tiramisu, pendant que d'autres parlent en infrarouge, c'est bien la vraie vie, n'est-ce pas ? -+- DA in Guide du Macounet Pervers : http://www.le-visconti.net/ -+- From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 10:57:14 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC47D16A41F for ; Thu, 29 Dec 2005 10:57:14 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from mallaury.nerim.net (smtp-104-thursday.noc.nerim.net [62.4.17.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4E3443D72 for ; Thu, 29 Dec 2005 10:57:06 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from srvbsdnanssv.interne.kisoft-services.com (kisoft.net1.nerim.net [62.212.107.51]) by mallaury.nerim.net (Postfix) with ESMTP id 0CA1F4F50A; Thu, 29 Dec 2005 11:56:58 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by srvbsdnanssv.interne.kisoft-services.com (Postfix) with ESMTP id 46F79C8D7; Thu, 29 Dec 2005 11:57:03 +0100 (CET) Received: from srvbsdnanssv.interne.kisoft-services.com ([127.0.0.1]) by localhost (srvbsdnanssv.interne.kisoft-services.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38958-08; Thu, 29 Dec 2005 11:57:01 +0100 (CET) Received: by srvbsdnanssv.interne.kisoft-services.com (Postfix, from userid 1001) id 9E61AC8D2; Thu, 29 Dec 2005 11:57:01 +0100 (CET) To: "Clark Gaylord" From: Eric Masson In-Reply-To: <1135852067.25722.250713284@webmail.messagingengine.com> (Clark Gaylord's message of "Thu, 29 Dec 2005 05:27:47 -0500") References: <20051228143817.GA6898@uk.tiscali.com> <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca> <20051228153106.GA7041@uk.tiscali.com> <20051228164339.GB3875@zen.inc> <43B38747.1060906@iteranet.com> <1135852067.25722.250713284@webmail.messagingengine.com> X-Operating-System: FreeBSD 5.4-RELEASE-p2 i386 Date: Thu, 29 Dec 2005 11:57:01 +0100 Message-ID: <86vex86uiq.fsf@srvbsdnanssv.interne.kisoft-services.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at interne.kisoft-services.com Cc: Alexey Popov , VANHULLEBUS Yvan , Brian Candler , freebsd-net@freebsd.org Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2005 10:57:14 -0000 "Clark Gaylord" writes: > Yeah, what is the story with that anyway? Is anyone working on it? Is > there hope? Iirc, Yvan made a patch (don't remember the target branch, sorry), but it seems that NAT-T might be patent encumbered (*). Anyway, Net & Open included NAT-T in their ip stacks some times ago. Éric Masson * : https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=78 -- «Tiens, quand j'aurai un peu de temps et une partition libre, je crois que je vais essayer de remplacer mes scripts de démarrage par des programmes Windows lancés via Wine et binfmt_misc :-)» -+- AGV in Guide du linuxien pervers - "J'sais pas quoi faire... (air connu)" From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 11:24:42 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9645316A41F for ; Thu, 29 Dec 2005 11:24:42 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from smtp4.mail.easynet.fr (smarthost174.mail.easynet.fr [212.180.1.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id 715B443D72 for ; Thu, 29 Dec 2005 11:24:32 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from easyconnect2121135-233.clients.easynet.fr ([212.11.35.233] helo=smtp.zeninc.net) by smtp4.mail.easynet.fr with esmtp (Exim 4.50) id 1Ervty-000540-Iy; Thu, 29 Dec 2005 12:24:58 +0100 Received: by smtp.zeninc.net (smtpd, from userid 1000) id 3D42F3F17; Thu, 29 Dec 2005 12:24:14 +0100 (CET) Date: Thu, 29 Dec 2005 12:24:14 +0100 From: VANHULLEBUS Yvan To: Alexey Popov Message-ID: <20051229112414.GA1257@zen.inc> References: <20051228143817.GA6898@uk.tiscali.com> <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca> <20051228153106.GA7041@uk.tiscali.com> <20051228164339.GB3875@zen.inc> <43B38747.1060906@iteranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43B38747.1060906@iteranet.com> User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-net@freebsd.org, Brian Candler Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2005 11:24:42 -0000 On Thu, Dec 29, 2005 at 09:50:47AM +0300, Alexey Popov wrote: > Hi. > > VANHULLEBUS Yvan wrote: > >>- L2TP + IPSEC transport mode (= Windows road warrier) > >Did someone tried such a setup ? > >is there a L2TPD daemon running on FreeBSD which could be used for > >that ? > I'm successfully using security/racoon and net/sl2tps with Windows > XP/2003 L2TP clients. I've tried pre-shared key as well as X.509 > certificates auth. Interesting, I'll try to play with that ! > >Note also that, for now, this won't work easily, as it will require > >dynamic SP entries (roadwarriors....), but I think racoon currently > >can't deal with dynamic policies when ports specified (I'll check > >that). > racoon has passive_mode option. When it is enabled, racoon can create > SPD entries for road warriors. Not exactly: generating policies works when racoon is responder (so passive_mode is just a safety check). And I was just talking about potential complex bundles (don't remember exactly what windows sends for phase2, but I think first proposals are AH+ESP, which will cause problem for generating policies with actual racoon's versions) and about policies with ports only (but perhaps I only had some problems with complex bundles when I had a quick look at such negociations). > If we would also have NAT-T support, FreeBSD would be the best choice > of VPN concentrator. Ipsec-tools port is set to natt "kernel autodetect", and I already have a working patch for FreeBSD6 (http://ipsec-tools.sf.net/freebsd6-natt.diff), which will need some more work (cleaner way of detecting kernel NAT-T support, sync with recent NetBSD devels, port to FAST-IPSEC, etc...), which are all on my (very busy) TODO list. Yvan. -- NETASQ - Secure Internet Connectivity http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 12:14:05 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65DF416A41F for ; Thu, 29 Dec 2005 12:14:05 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D23343D5D for ; Thu, 29 Dec 2005 12:14:04 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id C807AED; Thu, 29 Dec 2005 07:14:25 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 4831118D1; Thu, 29 Dec 2005 07:14:23 -0500 (EST) Received: from brian by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErwfQ-0002rp-1b; Thu, 29 Dec 2005 12:14:00 +0000 Date: Thu, 29 Dec 2005 12:14:00 +0000 From: Brian Candler To: Eric Masson Message-ID: <20051229121359.GA10949@uk.tiscali.com> References: <20051228143817.GA6898@uk.tiscali.com> <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca> <20051228153106.GA7041@uk.tiscali.com> <20051228164339.GB3875@zen.inc> <868xu5p2ze.fsf@srvbsdnanssv.interne.kisoft-services.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <868xu5p2ze.fsf@srvbsdnanssv.interne.kisoft-services.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, VANHULLEBUS Yvan Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2005 12:14:05 -0000 On Wed, Dec 28, 2005 at 06:04:37PM +0100, Eric Masson wrote: > > Did someone tried such a setup ? > > I plan to do so. > > Just have to find ios images that support l2tp and ipsec for my 1601R > or 2611 and bigger flash modules (I've been given them two weeks ago, > hardware upgrade is the easy part, for software, hope cisco will > permit hobbyist licences one of these days) > > > is there a L2TPD daemon running on FreeBSD which could be used for > > that ? > > ports/net/sl2tps I was rather surprised that I just got IPSEC tunnel mode working between Windows XP and FreeBSD; and then afterwards I also got transport mode + L2TP working using the Windows client and sl2tps. Zounds! There is a bug (arguably) in the ipsec-tools port, in that all useful messages are logged at level 'daemon.info', but the default syslog.conf discards these messages. Once that's fixed, debugging suddenly becomes a whole lot easier :-) I've submitted a PR. sl2tps seems flaky: it dumped core once at startup, although the backtrace was nothing I could make use of (see below), as I don't know how to debug a threaded application. It also desperately lacks the ability to authenticate against a RADIUS server. Once up, I can happily ping through the L2TP tunnel and run short telnet sessions but I can't view large web pages, which looks like an MTU issue. >From the PPP negotiation it lloks like an MRRU of 1600 is offered and rejected, and 1400 negotiated instead, which ought to be OK: debug: [192.168.1.200:1701]: LCP: event UP in state STARTING info: [192.168.1.200:1701]: LCP: xmit Conf-Req #0: [ACFComp] [PFComp] [Magic 0x4ae82076] [Auth CHAP-MD5] [MP-MRRU 1600] [MP-ShortSq] [EID IP:0.0.0.0] debug: [192.168.1.200:1701]: LCP: STARTING -> REQ-SENT info: [192.168.1.200:1701]: LCP: recv Conf-Rej #0: [MP-MRRU 1600] [MP-ShortSq] [EID IP:0.0.0.0] debug: [192.168.1.200:1701]: LCP: event RCN in state REQ-SENT info: [192.168.1.200:1701]: LCP: xmit Conf-Req #1: [ACFComp] [PFComp] [Magic 0x4ae82076] [Auth CHAP-MD5] info: [192.168.1.200:1701]: LCP: recv Conf-Ack #1: [ACFComp] [PFComp] [Magic 0x4ae82076] [Auth CHAP-MD5] debug: [192.168.1.200:1701]: LCP: event RCA in state REQ-SENT debug: [192.168.1.200:1701]: LCP: REQ-SENT -> ACK-RCVD info: [192.168.1.200:1701]: LCP: recv Conf-Req #1: [MRU 1400] [Magic 0x685733f2] [PFComp] [ACFComp] [Callback] debug: [192.168.1.200:1701]: LCP: event RCR- in state ACK-RCVD info: [192.168.1.200:1701]: LCP: xmit Conf-Rej #1: [Callback] info: [192.168.1.200:1701]: LCP: recv Conf-Req #2: [MRU 1400] [Magic 0x685733f2] [PFComp] [ACFComp] debug: [192.168.1.200:1701]: LCP: event RCR+ in state ACK-RCVD info: [192.168.1.200:1701]: LCP: xmit Conf-Ack #2: [MRU 1400] [Magic 0x685733f2] [PFComp] [ACFComp] debug: [192.168.1.200:1701]: LCP: ACK-RCVD -> OPENED A tcpdump on the external interface of the FreeBSD box is a bit strange though: the client chooses an mss of 1360 (= 1400 - 40 which is IP+TCP header), but the webserver chooses an mss of 1380 which is too large: 12:06:51.773708 IP myhost.60084 > www.example.com.80: S 3030435125:3030435125(0) win 65535 12:06:51.960445 IP www.example.com.80 > myhost.60084: S 4134768352:4134768352(0) ack 3030435126 win 65535 12:06:51.961377 IP myhost.60084 > www.example.com.80: . ack 1 win 65535 12:06:51.961922 IP myhost.60084 > www.example.com.80: P 1:299(298) ack 1 win 65535 12:06:52.136869 IP www.example.com.80 > myhost.60084: . 1:1361(1360) ack 299 win 65535 12:06:52.136959 IP myhost > www.example.com: ICMP myhost unreachable - need to frag, length 36 12:06:52.138064 IP www.example.com.80 > myhost.60084: . 1361:2721(1360) ack 299 win 65535 12:06:52.138125 IP myhost > www.example.com: ICMP myhost unreachable - need to frag, length 36 12:06:52.139195 IP www.example.com.80 > myhost.60084: . 2721:4081(1360) ack 299 win 65535 12:06:52.139256 IP myhost > www.example.com: ICMP myhost unreachable - need to frag, length 36 As it happens this FreeBSD box is also acting as a NAT gateway using pf (myhost is on a private IP) and actually its external IP is also private - it sits behind a second NAT firewall. So maybe that's where the problem originates, although I really can't understand where the value of 1380 comes from. Regards, Brian. GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `sl2tps'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libpdel.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpdel.so.0 Reading symbols from /usr/local/lib/libexpat.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libexpat.so.5 Reading symbols from /usr/lib/libssl.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libssl.so.4 Reading symbols from /lib/libcrypto.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypto.so.4 Reading symbols from /lib/libcrypt.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.3 Reading symbols from /usr/lib/libradius.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libradius.so.2 Reading symbols from /usr/lib/libnetgraph.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libnetgraph.so.2 Reading symbols from /usr/lib/libpthread.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libpthread.so.2 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x2825b2b7 in pthread_testcancel () from /usr/lib/libpthread.so.2 [New Thread 0x8056600 (runnable)] [New Thread 0x8056200 (LWP 100098)] [New Thread 0x8056000 (runnable)] [New LWP 100100] (gdb) bt #0 0x2825b2b7 in pthread_testcancel () from /usr/lib/libpthread.so.2 #1 0x28253dac in pthread_mutexattr_init () from /usr/lib/libpthread.so.2 #2 0x00000000 in ?? () (gdb) quit From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 12:25:55 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 502B516A41F for ; Thu, 29 Dec 2005 12:25:55 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id E310843D4C for ; Thu, 29 Dec 2005 12:25:53 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 31FBDBA; Thu, 29 Dec 2005 07:26:15 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id DAD7727EA; Thu, 29 Dec 2005 07:26:12 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Erwqr-0002t5-OB; Thu, 29 Dec 2005 12:25:49 +0000 Date: Thu, 29 Dec 2005 12:25:49 +0000 From: Brian Candler To: Alexey Popov Message-ID: <20051229122549.GA11055@uk.tiscali.com> References: <20051228143817.GA6898@uk.tiscali.com> <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca> <20051228153106.GA7041@uk.tiscali.com> <20051228164339.GB3875@zen.inc> <43B38747.1060906@iteranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43B38747.1060906@iteranet.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, VANHULLEBUS Yvan Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2005 12:25:55 -0000 On Thu, Dec 29, 2005 at 09:50:47AM +0300, Alexey Popov wrote: > If we would also have NAT-T support, FreeBSD would be the best choice > of VPN concentrator. /usr/ports/security/ipsec-tools/pkg-descr says: "Known issues: - Non-threaded implementation. Simultaneous key negotiation performance should be improved." I think that would limit its usefulness as a scalable concentrator, if the comment is still valid. From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 12:35:29 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 349FC16A41F for ; Thu, 29 Dec 2005 12:35:29 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from caine.easynet.fr (smarthost167.mail.easynet.fr [212.180.1.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id A76CC43D6B for ; Thu, 29 Dec 2005 12:35:28 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from easyconnect2121135-233.clients.easynet.fr ([212.11.35.233] helo=smtp.zeninc.net) by caine.easynet.fr with esmtp (Exim 4.50) id 1Erx0B-0001ry-O9 for freebsd-net@freebsd.org; Thu, 29 Dec 2005 13:35:28 +0100 Received: by smtp.zeninc.net (smtpd, from userid 1000) id A33E43F17; Thu, 29 Dec 2005 13:35:21 +0100 (CET) Date: Thu, 29 Dec 2005 13:35:21 +0100 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20051229123521.GA1854@zen.inc> References: <20051228143817.GA6898@uk.tiscali.com> <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca> <20051228153106.GA7041@uk.tiscali.com> <20051228164339.GB3875@zen.inc> <868xu5p2ze.fsf@srvbsdnanssv.interne.kisoft-services.com> <20051229121359.GA10949@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051229121359.GA10949@uk.tiscali.com> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2005 12:35:29 -0000 On Thu, Dec 29, 2005 at 12:14:00PM +0000, Brian Candler wrote: > On Wed, Dec 28, 2005 at 06:04:37PM +0100, Eric Masson wrote: [....] > > ports/net/sl2tps > > I was rather surprised that I just got IPSEC tunnel mode working between > Windows XP and FreeBSD; and then afterwards I also got transport mode + L2TP > working using the Windows client and sl2tps. Zounds! Very interesting, I'll try that ASAP ! > There is a bug (arguably) in the ipsec-tools port, in that all useful > messages are logged at level 'daemon.info', but the default syslog.conf > discards these messages. Once that's fixed, debugging suddenly becomes a > whole lot easier :-) I've submitted a PR. Got the mail about the PR, but I curently can't see the PR itself (PR database busy). I'll handle it as soon as I'll get the real PR. [....] > Once up, I can happily ping through the L2TP tunnel and run short telnet > sessions but I can't view large web pages, which looks like an MTU issue. Yep, that is the most probable reason ! > As it happens this FreeBSD box is also acting as a NAT gateway using pf > (myhost is on a private IP) and actually its external IP is also private - > it sits behind a second NAT firewall. So maybe that's where the problem > originates, although I really can't understand where the value of 1380 comes > from. 1500 - (pppoe encapsulation ?) - ESP header - L2TP encapsulation.... And perhaps another extra UDP encapsulation may be considered, but I guess you probably don't have NAT-T support. Yvan. -- NETASQ - Secure Internet Connectivity http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 12:38:22 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 972D616A41F for ; Thu, 29 Dec 2005 12:38:22 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from caine.easynet.fr (smarthost167.mail.easynet.fr [212.180.1.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D3F643D86 for ; Thu, 29 Dec 2005 12:38:17 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from easyconnect2121135-233.clients.easynet.fr ([212.11.35.233] helo=smtp.zeninc.net) by caine.easynet.fr with esmtp (Exim 4.50) id 1Erx2u-0000xP-Hv for freebsd-net@freebsd.org; Thu, 29 Dec 2005 13:38:16 +0100 Received: by smtp.zeninc.net (smtpd, from userid 1000) id 216653F17; Thu, 29 Dec 2005 13:38:15 +0100 (CET) Date: Thu, 29 Dec 2005 13:38:15 +0100 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20051229123815.GB1854@zen.inc> References: <20051228143817.GA6898@uk.tiscali.com> <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca> <20051228153106.GA7041@uk.tiscali.com> <20051228164339.GB3875@zen.inc> <43B38747.1060906@iteranet.com> <20051229122549.GA11055@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051229122549.GA11055@uk.tiscali.com> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2005 12:38:22 -0000 On Thu, Dec 29, 2005 at 12:25:49PM +0000, Brian Candler wrote: > On Thu, Dec 29, 2005 at 09:50:47AM +0300, Alexey Popov wrote: > > If we would also have NAT-T support, FreeBSD would be the best choice > > of VPN concentrator. > > /usr/ports/security/ipsec-tools/pkg-descr says: > > "Known issues: > - Non-threaded implementation. Simultaneous key negotiation performance > should be improved." > > I think that would limit its usefulness as a scalable concentrator, if the > comment is still valid. The comment is still valid, but impact is not so strong. Key negociations doesn't happen so much during an IPSec tunnel lifetime, and negociating simultaneous SAs will be slow even with a multi-threaded implementation if you have a low-end CPU. And if you have a high-end CPU, SAs will be negociated quickly, then the impact of negociating simultaneous SAs will be limited. Yvan. -- NETASQ - Secure Internet Connectivity http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 14:04:36 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C125A16A41F for ; Thu, 29 Dec 2005 14:04:36 +0000 (GMT) (envelope-from jan@melen.org) Received: from foxgw.melen.org (Savi-Mel.dna.fi [83.143.60.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6C7343D46 for ; Thu, 29 Dec 2005 14:04:33 +0000 (GMT) (envelope-from jan@melen.org) Received: from [2001:14b8:400:101::50] ([IPv6:2001:14b8:400:101::50]) (authenticated bits=0) by foxgw.melen.org (8.13.5/8.13.4) with ESMTP id jBTE4INI073072 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 29 Dec 2005 16:04:29 +0200 (EET) (envelope-from jan@melen.org) From: Jan Mikael Melen To: freebsd-net@freebsd.org Date: Thu, 29 Dec 2005 16:04:34 +0200 User-Agent: KMail/1.8.2 References: <20051228143817.GA6898@uk.tiscali.com> <20051229121359.GA10949@uk.tiscali.com> <20051229123521.GA1854@zen.inc> In-Reply-To: <20051229123521.GA1854@zen.inc> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512291604.39225.jan@melen.org> X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on foxgw.melen.org X-Virus-Status: Clean Cc: VANHULLEBUS Yvan Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2005 14:04:36 -0000 Hi, This now goes a little bit off topic from original subject of IPsec documentation, but we have made an implementation of the BEET (A Bound End to End Tunneling) mode IPsec on FreeBSD 5 and 6 (http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-04.txt). The implementation is part of our HIP (Host Identity Protocol) code and can be downloaded from the http://www.hip4inter.net/ through the download page. It might be interesting to include atleast the BEET mode code to the standard FreeBSD kernel at some point of time. We have made also modified the input handling of ESP to correspond the ESP-v3 where the SA is searched only based on the SPI value. Regards, Jan On Thursday 29 December 2005 14:35, VANHULLEBUS Yvan wrote: > On Thu, Dec 29, 2005 at 12:14:00PM +0000, Brian Candler wrote: > > On Wed, Dec 28, 2005 at 06:04:37PM +0100, Eric Masson wrote: > > [....] > > > > ports/net/sl2tps > > > > I was rather surprised that I just got IPSEC tunnel mode working between > > Windows XP and FreeBSD; and then afterwards I also got transport mode + > > L2TP working using the Windows client and sl2tps. Zounds! > > Very interesting, I'll try that ASAP ! > > > There is a bug (arguably) in the ipsec-tools port, in that all useful > > messages are logged at level 'daemon.info', but the default syslog.conf > > discards these messages. Once that's fixed, debugging suddenly becomes a > > whole lot easier :-) I've submitted a PR. > > Got the mail about the PR, but I curently can't see the PR itself (PR > database busy). I'll handle it as soon as I'll get the real PR. > > > [....] > > > Once up, I can happily ping through the L2TP tunnel and run short telnet > > sessions but I can't view large web pages, which looks like an MTU issue. > > Yep, that is the most probable reason ! > > > As it happens this FreeBSD box is also acting as a NAT gateway using pf > > (myhost is on a private IP) and actually its external IP is also private > > - it sits behind a second NAT firewall. So maybe that's where the problem > > originates, although I really can't understand where the value of 1380 > > comes from. > > 1500 - (pppoe encapsulation ?) - ESP header - L2TP encapsulation.... > > And perhaps another extra UDP encapsulation may be considered, but I > guess you probably don't have NAT-T support. > > > Yvan. From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 15:52:15 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4343716A41F for ; Thu, 29 Dec 2005 15:52:15 +0000 (GMT) (envelope-from squigly@xsmail.com) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C49B43D48 for ; Thu, 29 Dec 2005 15:52:14 +0000 (GMT) (envelope-from squigly@xsmail.com) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id B01FCD2EC0B for ; Thu, 29 Dec 2005 10:52:12 -0500 (EST) Received: from web2.messagingengine.com ([10.202.2.211]) by frontend1.internal (MEProxy); Thu, 29 Dec 2005 10:52:12 -0500 Received: by web2.messagingengine.com (Postfix, from userid 99) id 591012B2B; Thu, 29 Dec 2005 10:52:07 -0500 (EST) Message-Id: <1135871527.31733.250727230@webmail.messagingengine.com> X-Sasl-Enc: UWOyVOdAlW/Bl6C7gBBFO5iHknqaIT2wr9ZS6JXoTsYa 1135871527 From: "Squigly" To: freebsd-net@freebsd.org Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.5 (F2.73; T1.15; A1.64; B3.05; Q3.03) Date: Thu, 29 Dec 2005 07:52:07 -0800 Subject: Writing a netgraph module X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2005 15:52:15 -0000 Newbie question, sorry.. I want to develop netgraph module (something simple at first, but the intention is to write a full-fledged-real-world-bla-bla system). Problem is, I can't seem to find anything regarding the development process of a netgraph module. Google/Handbook/Forums didn't give much. I poked the code a bit (both for netgraph subsystem and some modules), but I do need something more basic to start with. Appriciate your help. Squigly. -- Squigly squigly@xsmail.com -- http://www.fastmail.fm - Faster than the air-speed velocity of an unladen european swallow From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 16:09:07 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 150EC16A420 for ; Thu, 29 Dec 2005 16:09:07 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABB0543D83 for ; Thu, 29 Dec 2005 16:08:57 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 7BE045D62; Thu, 29 Dec 2005 11:08:53 -0500 (EST) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48741-03; Thu, 29 Dec 2005 11:08:52 -0500 (EST) Received: from [192.168.1.3] (pool-68-161-122-227.ny325.east.verizon.net [68.161.122.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 45AFF5C8B; Thu, 29 Dec 2005 11:08:52 -0500 (EST) Message-ID: <43B40A23.7080502@mac.com> Date: Thu, 29 Dec 2005 11:09:07 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Squigly References: <1135871527.31733.250727230@webmail.messagingengine.com> In-Reply-To: <1135871527.31733.250727230@webmail.messagingengine.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: freebsd-net@freebsd.org Subject: Re: Writing a netgraph module X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2005 16:09:07 -0000 Squigly wrote: > I want to develop netgraph module (something simple at first, but the > intention is to write a full-fledged-real-world-bla-bla system). > > Problem is, I can't seem to find anything regarding the development > process of a netgraph module. > > Google/Handbook/Forums didn't give much. I poked the code a bit (both > for netgraph subsystem and some modules), > but I do need something more basic to start with. Does the following give you a starting point: cd /usr/src/sys/netgraph less NOTES ng_sample.[hc] -- -Chuck From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 16:46:10 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0010116A41F for ; Thu, 29 Dec 2005 16:46:09 +0000 (GMT) (envelope-from squigly@xsmail.com) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 681E343D60 for ; Thu, 29 Dec 2005 16:46:05 +0000 (GMT) (envelope-from squigly@xsmail.com) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id 8886CD2ECA6; Thu, 29 Dec 2005 11:46:03 -0500 (EST) Received: from web2.messagingengine.com ([10.202.2.211]) by frontend1.internal (MEProxy); Thu, 29 Dec 2005 11:46:03 -0500 Received: by web2.messagingengine.com (Postfix, from userid 99) id B8E79CBA4; Thu, 29 Dec 2005 11:45:57 -0500 (EST) Message-Id: <1135874757.4898.250730784@webmail.messagingengine.com> X-Sasl-Enc: x0/VfXElDWOWYJYvkJSN19+vK9c0vLPC5RHARRpD9q2v 1135874757 From: "Squigly" To: "Chuck Swiger" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.5 (F2.73; T1.15; A1.64; B3.05; Q3.03) References: <1135871527.31733.250727230@webmail.messagingengine.com> <43B40A23.7080502@mac.com> In-Reply-To: <43B40A23.7080502@mac.com> Date: Thu, 29 Dec 2005 08:45:57 -0800 Cc: freebsd-net@freebsd.org Subject: Re: Writing a netgraph module X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2005 16:46:10 -0000 On Thu, 29 Dec 2005 11:09:07 -0500, "Chuck Swiger" said: > Squigly wrote: > > I want to develop netgraph module (something simple at first, but the > > intention is to write a full-fledged-real-world-bla-bla system). > >=20 > > Problem is, I can't seem to find anything regarding the development > > process of a netgraph module. > >=20 > > Google/Handbook/Forums didn't give much. I poked the code a bit (both > > for netgraph subsystem and some modules), > > but I do need something more basic to start with. >=20 > Does the following give you a starting point: >=20 > cd /usr/src/sys/netgraph > less NOTES ng_sample.[hc] >=20 > --=20 > -Chuck Well.. yes and no. I did (of course) poked at that code, but again it gives you a rough example, and assume that you're already know your way with netgraph itself. I guess I need something more, hu, explainatory. Squigly --=20 Squigly squigly@xsmail.com --=20 http://www.fastmail.fm - Same, same, but different=85 From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 17:13:52 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5CCB16A41F for ; Thu, 29 Dec 2005 17:13:52 +0000 (GMT) (envelope-from zaa@ulstu.ru) Received: from kernel.ulstu.ru (kernel.ulstu.ru [62.76.34.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 060AD43D72 for ; Thu, 29 Dec 2005 17:13:46 +0000 (GMT) (envelope-from zaa@ulstu.ru) Received: from localhost (localhost [127.0.0.1]) by kernel.ulstu.ru (ulstuMail) with ESMTP id 9FF824ACC5; Thu, 29 Dec 2005 20:13:36 +0300 (MSK) Received: from kernel.ulstu.ru ([127.0.0.1]) by localhost (kernel.ulstu.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96111-06; Thu, 29 Dec 2005 20:13:36 +0300 (MSK) Received: from orion.ulstu.ru (orion.ulstu.ru [62.76.34.33]) by kernel.ulstu.ru (ulstuMail) with ESMTP id 7BC184AC21; Thu, 29 Dec 2005 20:13:32 +0300 (MSK) Received: by orion.ulstu.ru (Postfix, from userid 3909) id 2CDF7A4; Thu, 29 Dec 2005 20:13:32 +0300 (MSK) Date: Thu, 29 Dec 2005 20:13:32 +0300 From: Alexander Zhuravlev To: Squigly Message-ID: <20051229171331.GA24337@orion.ulstu.ru> Mail-Followup-To: Squigly , Chuck Swiger , freebsd-net@freebsd.org References: <1135871527.31733.250727230@webmail.messagingengine.com> <43B40A23.7080502@mac.com> <1135874757.4898.250730784@webmail.messagingengine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <1135874757.4898.250730784@webmail.messagingengine.com> X-Virus-Scanned: by amavisd-new at ulstu.ru Cc: freebsd-net@freebsd.org Subject: Re: Writing a netgraph module X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Zhuravlev List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2005 17:13:53 -0000 On Thu, Dec 29, 2005 at 08:45:57AM -0800, Squigly wrote: > Well.. yes and no. > I did (of course) poked at that code, but again it gives you a rough > example, and assume that you're already know your way with netgraph > itself. > > I guess I need something more, hu, explainatory. Maybe it would be more helpful if you try to get more details about netgraph architecture in general (and it will help you to understand C sources better): http://lists.freebsd.org/pipermail/freebsd-net/2005-December/009258.html Hope this helps :-) -- Alexander Zhuravlev From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 22:04:59 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F77D16A41F for ; Thu, 29 Dec 2005 22:04:59 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5F9143D55 for ; Thu, 29 Dec 2005 22:04:58 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 29 Dec 2005 14:04:58 -0800 X-IronPort-Anti-Spam-Filtered: true Message-ID: <43B45D8A.7040609@elischer.org> Date: Thu, 29 Dec 2005 14:04:58 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: forwarding icmp redirects. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2005 22:04:59 -0000 I know WE don't generate non local icmp redirects but I notice that we would forward them should someone else (malicious or not) generate them.. I think that we possibly should check for them in our forwarding code.. (of course you can stop them with the firewall but..) thoughts? From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 22:11:02 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95A4516A41F for ; Thu, 29 Dec 2005 22:11:02 +0000 (GMT) (envelope-from m.oe@x-trader.de) Received: from qhmail2.colt1.inetserver.de (qhmail2.colt1.inetserver.de [195.234.228.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0320D43D81 for ; Thu, 29 Dec 2005 22:10:56 +0000 (GMT) (envelope-from m.oe@x-trader.de) Received: from qhmx2-mailrouter.colt1.inetserver.de (qhmx2.colt1.inetserver.de [195.234.228.112]) by qhmail2.colt1.inetserver.de (Postfix) with ESMTP id 2B988B706 for ; Thu, 29 Dec 2005 23:10:55 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by qhmx2-mailrouter.colt1.inetserver.de (Postfix) with ESMTP id 0E9B43CA1C for ; Thu, 29 Dec 2005 23:10:55 +0100 (CET) Received: from qhmx2.colt1.inetserver.de ([127.0.0.1]) by localhost (qhmx2.colt1.inetserver.de [127.0.0.1]) (amavisd-new, port 10023) with LMTP id 67383-02 for ; Thu, 29 Dec 2005 23:10:54 +0100 (CET) X-Auth-User: markus@x-trader.de Received: from [192.168.100.100] (p54B25B39.dip.t-dialin.net [84.178.91.57]) by qhmx2-custsmtp.colt1.inetserver.de (Postfix) with ESMTP id 70E26B4796 for ; Thu, 29 Dec 2005 23:10:54 +0100 (CET) Message-ID: <43B45EEF.6060800@x-trader.de> Date: Thu, 29 Dec 2005 23:10:55 +0100 From: Markus Oestreicher User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at colt1.inetserver.de Subject: Routing SMP benefit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2005 22:11:02 -0000 Currently running a few routers on 5-STABLE I have read the recent changes in the network stack with interest. A few questions come to my mind: - Can a machine that mainly routes packets between two em(4) interfaces benefit from a second CPU and SMP kernel? Can both CPUs process packets from the same interface in parallel? - From reading the lists it appears that net.isr.direct and net.ip.fastforwarding are doing similar things. Should they be used together or rather not? Thank you! Markus From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 22:27:07 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD6CA16A41F for ; Thu, 29 Dec 2005 22:27:07 +0000 (GMT) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (p72-0-224-2.acedsl.com [72.0.224.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41D4343D4C for ; Thu, 29 Dec 2005 22:27:06 +0000 (GMT) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.13.4/8.13.4) with ESMTP id jBTMOZsA047997; Thu, 29 Dec 2005 17:24:35 -0500 (EST) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.13.4/8.13.3/Submit) id jBTMOZ3W047996; Thu, 29 Dec 2005 17:24:35 -0500 (EST) (envelope-from barney) Date: Thu, 29 Dec 2005 17:24:35 -0500 From: Barney Wolff To: Julian Elischer Message-ID: <20051229222435.GA32141@pit.databus.com> References: <43B45D8A.7040609@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43B45D8A.7040609@elischer.org> User-Agent: Mutt/1.5.11 Cc: FreeBSD Net Subject: Re: forwarding icmp redirects. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2005 22:27:07 -0000 On Thu, Dec 29, 2005 at 02:04:58PM -0800, Julian Elischer wrote: > I know WE don't generate non local icmp redirects but I notice that we > would forward them should someone else (malicious or not) generate them.. > I think that we possibly should check for them in our forwarding code.. > (of course you can stop them with the firewall but..) Why this particular one out of the semi-infinite set of malicious packets? If I had to pick one, I'd drop packets arriving with a source IP that we think is one of ours. But in general I think FreeBSD should obey RFCs and match the good behavior of widely used commercial routers. -- Barney Wolff http://www.databus.com/bwresume.pdf I never met a computer I didn't like. From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 22:28:40 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA99816A41F for ; Thu, 29 Dec 2005 22:28:40 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEFE543D79 for ; Thu, 29 Dec 2005 22:28:29 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 29 Dec 2005 14:28:28 -0800 X-IronPort-Anti-Spam-Filtered: true Message-ID: <43B4630C.3060807@elischer.org> Date: Thu, 29 Dec 2005 14:28:28 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexander Zhuravlev References: <1135871527.31733.250727230@webmail.messagingengine.com> <43B40A23.7080502@mac.com> <1135874757.4898.250730784@webmail.messagingengine.com> <20051229171331.GA24337@orion.ulstu.ru> In-Reply-To: <20051229171331.GA24337@orion.ulstu.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Squigly , freebsd-net@freebsd.org Subject: Re: Writing a netgraph module X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2005 22:28:40 -0000 Alexander Zhuravlev wrote: >On Thu, Dec 29, 2005 at 08:45:57AM -0800, Squigly wrote: > > >>Well.. yes and no. >>I did (of course) poked at that code, but again it gives you a rough >>example, and assume that you're already know your way with netgraph >>itself. >> >>I guess I need something more, hu, explainatory. >> >> > > Maybe it would be more helpful if you try to get more > details about netgraph architecture in general (and it will help > you to understand C sources better): > > http://lists.freebsd.org/pipermail/freebsd-net/2005-December/009258.html > > Hope this helps :-) > > > Also look at archie's article on netgraph on Daemonnews.org. From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 22:50:42 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3014B16A41F for ; Thu, 29 Dec 2005 22:50:42 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD07A43D48 for ; Thu, 29 Dec 2005 22:50:41 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 29 Dec 2005 14:50:41 -0800 X-IronPort-Anti-Spam-Filtered: true Message-ID: <43B46841.1030107@elischer.org> Date: Thu, 29 Dec 2005 14:50:41 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexander Zhuravlev References: <1135871527.31733.250727230@webmail.messagingengine.com> <43B40A23.7080502@mac.com> <1135874757.4898.250730784@webmail.messagingengine.com> <20051229171331.GA24337@orion.ulstu.ru> In-Reply-To: <20051229171331.GA24337@orion.ulstu.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Squigly , freebsd-net@freebsd.org Subject: Re: Writing a netgraph module X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2005 22:50:42 -0000 Alexander Zhuravlev wrote: >On Thu, Dec 29, 2005 at 08:45:57AM -0800, Squigly wrote: > > >>Well.. yes and no. >>I did (of course) poked at that code, but again it gives you a rough >>example, and assume that you're already know your way with netgraph >>itself. >> >>I guess I need something more, hu, explainatory. >> >> > > Maybe it would be more helpful if you try to get more > details about netgraph architecture in general (and it will help > you to understand C sources better): > > http://lists.freebsd.org/pipermail/freebsd-net/2005-December/009258.html > > Hope this helps :-) > > > probably not too much.. :-) has anyome actually looked at it? :-) I can't get to Archie's doc on Daemonnews at the moment so here's my copy: http://people.freebsd.org/~julian/netgraph.html From owner-freebsd-net@FreeBSD.ORG Fri Dec 30 00:07:18 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD6DC16A41F for ; Fri, 30 Dec 2005 00:07:18 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB0E243D49 for ; Fri, 30 Dec 2005 00:07:10 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 76648 invoked from network); 30 Dec 2005 00:12:08 -0000 Received: from c00l3r.networx.ch (HELO freebsd.org) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Dec 2005 00:12:08 -0000 Message-ID: <43B47A31.2CABFD7D@freebsd.org> Date: Fri, 30 Dec 2005 01:07:13 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer References: <43B45D8A.7040609@elischer.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: forwarding icmp redirects. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2005 00:07:18 -0000 Julian Elischer wrote: > > I know WE don't generate non local icmp redirects but I notice that we > would forward them should someone else (malicious or not) generate them.. > I think that we possibly should check for them in our forwarding code.. > (of course you can stop them with the firewall but..) > > thoughts? The job of the forwarding code is to forward packets with little to no exceptions. Dropping certain types of ICMP packets is out of scope for the forwarding code. The proper place is a firewall. IMHO we should disable emitting and acting upon ICMP redirects by default. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Dec 30 00:17:55 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6084F16A41F for ; Fri, 30 Dec 2005 00:17:55 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEDD143D5E for ; Fri, 30 Dec 2005 00:17:53 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 76769 invoked from network); 30 Dec 2005 00:22:52 -0000 Received: from c00l3r.networx.ch (HELO freebsd.org) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Dec 2005 00:22:52 -0000 Message-ID: <43B47CB5.3C0F1632@freebsd.org> Date: Fri, 30 Dec 2005 01:17:57 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Markus Oestreicher References: <43B45EEF.6060800@x-trader.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Routing SMP benefit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2005 00:17:55 -0000 Markus Oestreicher wrote: > > Currently running a few routers on 5-STABLE I have read the > recent changes in the network stack with interest. You should run 6.0R. It contains many improvements over 5-STABLE. > A few questions come to my mind: > > - Can a machine that mainly routes packets between two em(4) > interfaces benefit from a second CPU and SMP kernel? Can both > CPUs process packets from the same interface in parallel? My testing has shown that a machine can benefit from it but not much in the forwarding performance. The main benefit is the prevention of lifelock if you have very high packet loads. The second CPU on SMP keeps on doing all userland tasks and running routing protocols. Otherwise your BGP sessions or OSPF hellos would stop and remove you from the routing cloud. > - From reading the lists it appears that net.isr.direct > and net.ip.fastforwarding are doing similar things. Should > they be used together or rather not? net.inet.ip.fastforwarding has precedence over net.isr.direct and enabling both at the same doesn't gain you anything. Fastforwarding is about 30% faster than all other methods available, including polling. On my test machine with two em(4) and an AMD Opteron 852 (2.6GHz) I can route 580'000 pps with zero packet loss on -CURRENT. An upcoming optimization that will go into -CURRENT in the next few days pushes that to 714'000 pps. Futher optimizations are underway to make a stock kernel do close to or above 1'000'000 pps on the same hardware. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Dec 30 05:01:55 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 10BE816A41F; Fri, 30 Dec 2005 05:01:55 +0000 (GMT) (envelope-from julian@elischer.org) Received: from delight.idiom.com (outbound.idiom.com [216.240.47.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 854E243D55; Fri, 30 Dec 2005 05:01:52 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id 06FE22297D8; Thu, 29 Dec 2005 21:01:52 -0800 (PST) Received: from [192.168.2.4] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id jBU51oa7016192; Thu, 29 Dec 2005 21:01:51 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <43B4BF3E.9070907@elischer.org> Date: Thu, 29 Dec 2005 21:01:50 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051120 X-Accept-Language: en, hu MIME-Version: 1.0 To: Andre Oppermann References: <43B45D8A.7040609@elischer.org> <43B47A31.2CABFD7D@freebsd.org> In-Reply-To: <43B47A31.2CABFD7D@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: forwarding icmp redirects. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2005 05:01:55 -0000 Andre Oppermann wrote: > Julian Elischer wrote: > >>I know WE don't generate non local icmp redirects but I notice that we >>would forward them should someone else (malicious or not) generate them.. >>I think that we possibly should check for them in our forwarding code.. >>(of course you can stop them with the firewall but..) >> >>thoughts? > > > The job of the forwarding code is to forward packets with little to > no exceptions. Dropping certain types of ICMP packets is out of scope > for the forwarding code. The proper place is a firewall. > > IMHO we should disable emitting and acting upon ICMP redirects by default. I know many places that rely on them heavily.. please don't do that.. Cisco PIX doesn't generate them.. it makes that machine a pain in the **** to use in some situations. > From owner-freebsd-net@FreeBSD.ORG Fri Dec 30 12:11:56 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C7A116A41F for ; Fri, 30 Dec 2005 12:11:56 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CDC743D46 for ; Fri, 30 Dec 2005 12:11:54 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 11C3095; Fri, 30 Dec 2005 07:12:15 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id AC8942969; Fri, 30 Dec 2005 07:12:13 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EsJ6s-0003oR-Pg; Fri, 30 Dec 2005 12:11:50 +0000 Date: Fri, 30 Dec 2005 12:11:50 +0000 From: Brian Candler To: VANHULLEBUS Yvan Message-ID: <20051230121150.GA14630@uk.tiscali.com> References: <20051228143817.GA6898@uk.tiscali.com> <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca> <20051228153106.GA7041@uk.tiscali.com> <20051228164339.GB3875@zen.inc> <868xu5p2ze.fsf@srvbsdnanssv.interne.kisoft-services.com> <20051229121359.GA10949@uk.tiscali.com> <20051229123521.GA1854@zen.inc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051229123521.GA1854@zen.inc> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2005 12:11:56 -0000 On Thu, Dec 29, 2005 at 01:35:21PM +0100, VANHULLEBUS Yvan wrote: > > As it happens this FreeBSD box is also acting as a NAT gateway using pf > > (myhost is on a private IP) and actually its external IP is also private - > > it sits behind a second NAT firewall. So maybe that's where the problem > > originates, although I really can't understand where the value of 1380 comes > > from. > > 1500 - (pppoe encapsulation ?) - ESP header - L2TP encapsulation.... Yeah, but what I don't understand is that this value was chosen by a remote webserver which is on the other side of the world, and knows nothing about the L2TP/ESP encapsulation going on locally. All it knows is that the client offered an MSS of 1360; for some reason it offered back an MSS of 1380. Weird. From owner-freebsd-net@FreeBSD.ORG Fri Dec 30 12:17:12 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C47016A41F for ; Fri, 30 Dec 2005 12:17:12 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BA8143D78 for ; Fri, 30 Dec 2005 12:17:11 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 81DD3D6; Fri, 30 Dec 2005 07:17:32 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 40DB623BD; Fri, 30 Dec 2005 07:17:31 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EsJC0-0003oa-4j; Fri, 30 Dec 2005 12:17:08 +0000 Date: Fri, 30 Dec 2005 12:17:08 +0000 From: Brian Candler To: VANHULLEBUS Yvan Message-ID: <20051230121708.GB14630@uk.tiscali.com> References: <20051228143817.GA6898@uk.tiscali.com> <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca> <20051228153106.GA7041@uk.tiscali.com> <20051228164339.GB3875@zen.inc> <43B38747.1060906@iteranet.com> <20051229122549.GA11055@uk.tiscali.com> <20051229123815.GB1854@zen.inc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051229123815.GB1854@zen.inc> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2005 12:17:12 -0000 On Thu, Dec 29, 2005 at 01:38:15PM +0100, VANHULLEBUS Yvan wrote: > > "Known issues: > > - Non-threaded implementation. Simultaneous key negotiation performance > > should be improved." > > > > I think that would limit its usefulness as a scalable concentrator, if the > > comment is still valid. > > The comment is still valid, but impact is not so strong. > > Key negociations doesn't happen so much during an IPSec tunnel > lifetime, and negociating simultaneous SAs will be slow even with a > multi-threaded implementation if you have a low-end CPU. You could have a crypto accelerator card even in a low-end CPU. My concern is with long network RTTs to the clients, and packet loss. Anything like that which slows down the exchange will block out other clients from negotiating, if I understand rightly. With 10,000 clients and a phase 2 SA lifetime of one hour, that's a lot of negotiations going on, and one badly-behaved connection could cause a backlog of outstanding SA negotiations and probably a meltdown. Another issue is with DoS. Is it possible for an attacker to start an IKE exchange and get sufficiently far through it that they can block out other negotiations, before getting to the point of needing to provide valid credentials? Regards, Brian. From owner-freebsd-net@FreeBSD.ORG Fri Dec 30 12:34:47 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E589C16A41F; Fri, 30 Dec 2005 12:34:47 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id C880443D48; Fri, 30 Dec 2005 12:34:46 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id CA6E8E5; Fri, 30 Dec 2005 07:35:07 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 725851EC3; Fri, 30 Dec 2005 07:35:05 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EsJT0-0003pG-Av; Fri, 30 Dec 2005 12:34:42 +0000 Date: Fri, 30 Dec 2005 12:34:42 +0000 From: Brian Candler To: Julian Elischer Message-ID: <20051230123442.GC14630@uk.tiscali.com> References: <43B45D8A.7040609@elischer.org> <43B47A31.2CABFD7D@freebsd.org> <43B4BF3E.9070907@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43B4BF3E.9070907@elischer.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, Andre Oppermann Subject: Re: forwarding icmp redirects. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2005 12:34:48 -0000 On Thu, Dec 29, 2005 at 09:01:50PM -0800, Julian Elischer wrote: > >IMHO we should disable emitting and acting upon ICMP redirects by default. > > I know many places that rely on them heavily.. please don't do that.. > Cisco PIX doesn't generate them.. it makes that machine a pain in the **** > to use in some situations. But you can always turn them back on if you need them. I also vote for disabling ICMP redirects by default, from painful experience. One place I worked many years ago had a pair of Cisco border routers as gateways to the outside world. They talked iBGP to each other, but just HSRP on the local network, i.e. there was a single shared IP address which the servers pointed defaultroute to. Whenever a client machine sent a packet to X.X.X.X on the Internet, it would hit whichever router was the HSRP master. If BGP said that the best egress route was via the other router, it would forward the packet to the other router but also send back an ICMP redirect saying "to reach X.X.X.X in future use Z.Z.Z.Z as your next hop" (Z.Z.Z.Z being the other Cisco's own IP) So, lots of machines on the network starting building up *permanent* forwarding table entries saying that X.X.X.X should be reached via Z.Z.Z.Z. As a result, on the day that the second router died, half the Internet became unreachable from those machines. So much for resilience! The solution was to turn off the generation of redirects on the Ciscos, followed by lots of route flushing everywhere else. But the moral is: ICMP redirects are evil and are no substitute for a routing protocol. Regards, Brian. From owner-freebsd-net@FreeBSD.ORG Fri Dec 30 12:40:03 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 463EF16A420 for ; Fri, 30 Dec 2005 12:40:03 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9471D43D58 for ; Fri, 30 Dec 2005 12:40:01 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 82319 invoked from network); 30 Dec 2005 12:44:54 -0000 Received: from c00l3r.networx.ch (HELO freebsd.org) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Dec 2005 12:44:54 -0000 Message-ID: <43B52AA7.EA05579A@freebsd.org> Date: Fri, 30 Dec 2005 13:40:07 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian Candler References: <43B45D8A.7040609@elischer.org> <43B47A31.2CABFD7D@freebsd.org> <43B4BF3E.9070907@elischer.org> <20051230123442.GC14630@uk.tiscali.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Julian Elischer Subject: Re: forwarding icmp redirects. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2005 12:40:03 -0000 Brian Candler wrote: > > On Thu, Dec 29, 2005 at 09:01:50PM -0800, Julian Elischer wrote: > > >IMHO we should disable emitting and acting upon ICMP redirects by default. > > > > I know many places that rely on them heavily.. please don't do that.. > > Cisco PIX doesn't generate them.. it makes that machine a pain in the **** > > to use in some situations. > > But you can always turn them back on if you need them. > > I also vote for disabling ICMP redirects by default, from painful > experience. > > One place I worked many years ago had a pair of Cisco border routers as > gateways to the outside world. They talked iBGP to each other, but just HSRP > on the local network, i.e. there was a single shared IP address which the > servers pointed defaultroute to. > > Whenever a client machine sent a packet to X.X.X.X on the Internet, it would > hit whichever router was the HSRP master. If BGP said that the best egress > route was via the other router, it would forward the packet to the other > router but also send back an ICMP redirect saying "to reach X.X.X.X in > future use Z.Z.Z.Z as your next hop" (Z.Z.Z.Z being the other Cisco's own > IP) > > So, lots of machines on the network starting building up *permanent* > forwarding table entries saying that X.X.X.X should be reached via Z.Z.Z.Z. > As a result, on the day that the second router died, half the Internet > became unreachable from those machines. So much for resilience! > > The solution was to turn off the generation of redirects on the Ciscos, > followed by lots of route flushing everywhere else. But the moral is: ICMP > redirects are evil and are no substitute for a routing protocol. Indeed. And another problem with ICMP redirects is that they only create host routes. If you have a server with clients on the big wide Internet you'll get thousands to hundred-thousands of host routes from redirects. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Dec 30 12:47:01 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A1F016A41F for ; Fri, 30 Dec 2005 12:47:01 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from smtp3.mail.easynet.fr (smarthost173.mail.easynet.fr [212.180.1.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7B3443D55 for ; Fri, 30 Dec 2005 12:47:00 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from easyconnect2121135-233.clients.easynet.fr ([212.11.35.233] helo=smtp.zeninc.net) by smtp3.mail.easynet.fr with esmtp (Exim 4.50) id 1EsJfF-0004SP-Pc for freebsd-net@freebsd.org; Fri, 30 Dec 2005 13:47:22 +0100 Received: by smtp.zeninc.net (smtpd, from userid 1000) id 90A693F17; Fri, 30 Dec 2005 13:46:57 +0100 (CET) Date: Fri, 30 Dec 2005 13:46:57 +0100 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20051230124657.GA22834@zen.inc> References: <20051228143817.GA6898@uk.tiscali.com> <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca> <20051228153106.GA7041@uk.tiscali.com> <20051228164339.GB3875@zen.inc> <43B38747.1060906@iteranet.com> <20051229122549.GA11055@uk.tiscali.com> <20051229123815.GB1854@zen.inc> <20051230121708.GB14630@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051230121708.GB14630@uk.tiscali.com> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2005 12:47:01 -0000 On Fri, Dec 30, 2005 at 12:17:08PM +0000, Brian Candler wrote: [simultaneous negociations] > You could have a crypto accelerator card even in a low-end CPU. Yep, but it doesn't help so much, for the same reasons. Crypto accelerator for IPSec traffic is really more important ! > My concern is with long network RTTs to the clients, and packet loss. > Anything like that which slows down the exchange will block out other > clients from negotiating, if I understand rightly. No. basically, racoon just process incoming messages (from kernel or from network) one by one, but simultaneous SAs can be negociated with various peers at the same time. > With 10,000 clients and a phase 2 SA lifetime of one hour, that's a lot of > negotiations going on, and one badly-behaved connection could cause a > backlog of outstanding SA negotiations and probably a meltdown. 1 hour for phase2 is "quite short" (well, it is NOT too short, lifetimes of a few minuts are too short), compared to 1 day as default value for many vendors. And once again, one stalled negociation will NOT block others. Yvan. -- NETASQ - Secure Internet Connectivity http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Fri Dec 30 15:10:29 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDA1116A41F for ; Fri, 30 Dec 2005 15:10:29 +0000 (GMT) (envelope-from piston@otel.net) Received: from mail.otel.net (ll.otel.net [212.36.8.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6397F43D55 for ; Fri, 30 Dec 2005 15:10:28 +0000 (GMT) (envelope-from piston@otel.net) Received: from devilspot.otel.net ([212.36.8.194]) by mail.otel.net with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EsLti-000HEf-SQ for freebsd-net@freebsd.org; Fri, 30 Dec 2005 17:10:27 +0200 Date: Fri, 30 Dec 2005 17:10:45 +0200 From: "S.I" To: freebsd-net@freebsd.org Message-Id: <20051230171045.234b4cc7.piston@otel.net> Organization: OTEL.net X-Mailer: Sylpheed version 2.0.4 (GTK+ 2.8.8; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: cpu?bsnmp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2005 15:10:30 -0000 hi, I want to monitor my CPU with bsnmpd but I don't want to use external (prog, script). Any Ideas for that. From owner-freebsd-net@FreeBSD.ORG Sat Dec 31 02:52:16 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 724A116A41F for ; Sat, 31 Dec 2005 02:52:16 +0000 (GMT) (envelope-from reverselogic@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5D0643D49 for ; Sat, 31 Dec 2005 02:52:15 +0000 (GMT) (envelope-from reverselogic@gmail.com) Received: by nproxy.gmail.com with SMTP id o60so244075nfa for ; Fri, 30 Dec 2005 18:52:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=cUyssd1+0DuCfYybHT0tzj0VDVvQcUcmPObgR5tLPans1va5U5JElWuFJ+8SHmzcbVNYLUzJ1f4B3bzxNqCZYt8jfyvggRva67I0HDSvTOkcz1Lc9LsHY15tcmKJznjkFNWt0EqPNaDR0/M6mZwwjY+2/JqpH4k9Bn8HbhGZUPE= Received: by 10.48.49.20 with SMTP id w20mr432815nfw; Fri, 30 Dec 2005 18:52:14 -0800 (PST) Received: by 10.48.217.10 with HTTP; Fri, 30 Dec 2005 18:52:14 -0800 (PST) Message-ID: Date: Sat, 31 Dec 2005 02:52:14 +0000 From: Paul To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: FreeBSD 6.0 release, X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2005 02:52:16 -0000 I've just installed FreeBSD 6.0 Release yesterday, I've spend the last two days trying to resolve a networking problem, the problem is this: when I try and connect to a domain or an IP for that matter, it takes several minutes for it to connect + receive the content. It doesn't seem to effect all addresses though, I've had no problems connecting to ftp://ftp.freebsd.org to download software etc., nor have I had any problems connecting to domains inside my LAN. As far as I can tell, it isn't a dns problem because I can ping without any problems. I would really appreciate any advice anybody can give me. I've included some information below which may help diagnose the problem. Thanks, Paul // uname -a FreeBSD darkstar.home 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Thu Nov 3 09:36:13 UTC 2005 =20 root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC i386 // ifconfig rl0: flags=3D8843 mtu 1500 options=3D8 inet6 fe80::210:b5ff:fede:6e8b%rl0 prefixlen 64 scopeid 0x1 inet 192.168.0.102 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:10:b5:de:6e:8b media: Ethernet autoselect (10baseT/UTP) status: active plip0: flags=3D108851 mtu 1500 inet 0.0.0.0 --> 255.255.255.255 netmask 0xff000000 lo0: flags=3D8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 // dmesg | grep rl0 rl0: port 0x1000-0x10ff mem 0x40000000-0x400000ff irq 16 at device 8.0 on pci2 miibus0: on rl0 rl0: Ethernet address: 00:10:b5:de:6e:8b From owner-freebsd-net@FreeBSD.ORG Sat Dec 31 07:11:13 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFA7E16A41F; Sat, 31 Dec 2005 07:11:13 +0000 (GMT) (envelope-from mi@roo.bychok.com) Received: from roo.bychok.com (cpe-68-173-160-72.nyc.res.rr.com [68.173.160.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 463F143D4C; Sat, 31 Dec 2005 07:11:13 +0000 (GMT) (envelope-from mi@roo.bychok.com) Received: from roo.bychok.com (localhost [127.0.0.1]) by roo.bychok.com (8.13.4/8.13.4) with ESMTP id jBV7BCBg000928; Sat, 31 Dec 2005 02:11:12 -0500 (EST) (envelope-from mi@roo.bychok.com) Received: (from mi@localhost) by roo.bychok.com (8.13.4/8.13.4/Submit) id jBV7BBjM000927; Sat, 31 Dec 2005 02:11:11 -0500 (EST) (envelope-from mi) Date: Sat, 31 Dec 2005 02:11:11 -0500 (EST) From: Mikhail Teterin Message-Id: <200512310711.jBV7BBjM000927@roo.bychok.com> To: current@FreeBSD.org, net@FreeBSD.org Cc: Subject: Troubles with outgoing TCP connections X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mi@aldan.algebra.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2005 07:11:14 -0000 Hello! I was experiencing serious problems with web-browsing on this one machine -- various sites would sometimes be very slow or timeout altogether. A Windows machine on the other desk is plugged into the same NAT-router going over to the same cable modem. It is running the same version of Firefox and has no problems whatsoever. Actually, the browser can be ruled out as the cause -- even the following simple script while (1) date fetch -o /dev/null http://www.FreeBSD.org/ sleep 0.5 end hangs every 5-8 cycles (the fetch process usually stays in "connect" state for a minute or so and then times out). I also noticed, that ssh-ing out from this machine is broken :-( The outgoing connection abruptly closes all the time. I went through the kernel config file and removed all the IPSEC and IPFW stuff, as well as VFA_AIO. The problem still exists. This box was my main machine for years -- running 4.x and 5.x fine. After rebuilding it with 6.0 I'm stuck with this mistery. Any hope? If you wish to look around -- contact me privately for an account. Inbound connections seem fine. Thanks! -mi