From owner-freebsd-net@FreeBSD.ORG Sun Oct 23 00:18: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 6433B16A41F for ; Sun, 23 Oct 2005 00:18:05 +0000 (GMT) (envelope-from jay@codegurus.org) Received: from ptb-relay01.plus.net (ptb-relay01.plus.net [212.159.14.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC4F743D45 for ; Sun, 23 Oct 2005 00:18:04 +0000 (GMT) (envelope-from jay@codegurus.org) Received: from jayton.plus.com ([84.92.156.191] helo=[127.0.0.1]) by ptb-relay01.plus.net with esmtp (Exim) id 1ETTYm-0006HZ-3S; Sun, 23 Oct 2005 01:18:01 +0100 Message-ID: <435AD6B5.9050109@codegurus.org> Date: Sun, 23 Oct 2005 01:17:57 +0100 From: Jayton Garnett User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: andy@triera.net References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Problem with firewall 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: Sun, 23 Oct 2005 00:18:05 -0000 Andy Rozman (Aleksander) wrote: >Hi ! > >I am sorry to post this message here, but I think that there are a lot of >gurus here, who could help me without a problem. > >Tilll now I was running ipfw with rule that allows all packets (from kernel) >to pass through. In last few weeks I started having problems, since I got >quite a lot of packets that server accepted by default. > >So I removed this kernel directive out, but now I have problem, that I don't >know how to set rules. I have on my FreeBSD box two NICs, one for outside >internet, and one for internal network, so I am using this machine as router, >and as web server,... > >Problem is that I don't know how to set the rules so that ipfw will allow all >directives from inside network to go out, and receive replies. Please send me >working config. I tried several configs I found on net, but none of them seem >to work... It would probably also be nice to put one working natd + ipfw >confguration somewhere in handbook. > >Please help. >Andy > >P.S: I applied for memebership to list, but I don't know how fast this will be >procesed, so please cc to my email. > > Hello Andy, Last night I faced a similar problem since ndiscvt on fbsd 5.4 64bit would not procude the required ndis_driver_data.h file for my wifi card, ndiscvt produced it on fbsd 5.4 x86, so a friend helped me out and I kind of understand what you need. I didn't get mine working because i'm too impatient and my internet connection went down for a few minutes, in that time I dug out my hub/cat5 patch cables and ran them to my router instead of going something like this: Main PC --> Gateway --> Router --> Internet It now goes like this (and so does the rest of the network): Main PC --> Router --> Internet Presuming you are using a cable modem with no router in between it and your server/router. Hope it works for you! Cheers, Jayton in your /etc/rc.conf you should have something like this: gateway_enable="YES" hostname="yourdomain.com" ifconfig_rl0="DHCP" ifconfig_rl1="inet 192.168.0.1 netmask 255.255.255.0" defaultrouter="192.168.0.1" # firewall stuff firewall_enable="YES" firewall_script="/etc/rc.firewall" firewall_quiet="NO" firewall_flags="" # natd stuff natd_enable="YES" natd_interface="rl0" natd_flags="-f /etc/natd.conf" in your /etc/natd.conf interface rl0 redirect_port tcp 192.168.0.3:2090 2090 redirect_port tcp 192.168.0.3:2091 2091 redirect_port tcp 192.168.0.3:2092 2092 redirect_port tcp 192.168.0.3:2093 2093 redirect_port tcp 192.168.0.3:2094 2094 redirect_port tcp 192.168.0.3:2095 2095 redirect_port udp 192.168.0.3:2090 2090 redirect_port udp 192.168.0.3:2091 2091 redirect_port udp 192.168.0.3:2092 2092 redirect_port udp 192.168.0.3:2093 2093 redirect_port udp 192.168.0.3:2094 2094 redirect_port udp 192.168.0.3:2095 2095 redirect_port tcp 192.168.0.3:2000 2000 redirect_port tcp 192.168.0.3:2001 2001 redirect_port tcp 192.168.0.3:2002 2002 redirect_port tcp 192.168.0.3:2003 2003 redirect_port tcp 192.168.0.3:2004 2004 redirect_port udp 192.168.0.3:2000 2000 redirect_port udp 192.168.0.3:2001 2001 redirect_port udp 192.168.0.3:2002 2002 redirect_port udp 192.168.0.3:2003 2003 redirect_port udp 192.168.0.3:2004 2004 in your /etc/rc.firewall in /etc if it does not exist and add this in and see what happens #!/bin/sh # Set rules command prefix # The -q option on the command is for quite mode. # Do not display rules as they load. Remove during development to see. fwcmd="/sbin/ipfw" # set these to your outside interface network and netmask and ip oif="rl0" iif="rl1" inet="192.168.0.2" imask="255.255.255.0" iip="192.168.0.2" ############ # Flush out the list before we begin. # ${fwcmd} -f flush ############ # mandatory # ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny all from any to 127.0.0.0/8 ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any # Stop spoofing ${fwcmd} add deny all from ${inet}:${imask} to any in via ${oif} # exempt everything behind the firewall from this rules set $fwcmd add pass ip from any to any via sis1 # allow all internal traffic #turn on statefull firewall ${fwcmd} add check-state # Allow the packet through if it has previous been added to the # the "dynamic" rules table by an allow keep-state statement. $fwcmd add allow tcp from any to any established # Deny IP fragments to pass through #${fwcmd} add deny all from any to any frag ################################################################################ # allow outoing connexions to specified TCP ports # ################################################################################ #allow everything ${fwcmd} add pass tcp from any to any 1-65535 out via ${oif} setup keep-state ${fwcmd} add pass udp from any to any 1-65535 out via ${oif} setup keep-state # Allow setup of http to the outside ${fwcmd} add pass tcp from any to any 80 out via ${oif} setup keep-state # Allow setup of ssh to the outside ${fwcmd} add pass tcp from any to any 22 out via ${oif} setup keep-state # Allow setup of CVSUP to the outside ${fwcmd} add allow tcp from any to any 5999 out via ${oif} setup keep-state # Allow GRE (IPSEC) ${fwcmd} add pass gre from any to any keep-state # Allow setup of https to the outside #${fwcmd} add pass tcp from any to any 443 out via ${oif} setup keep-state # Allow setup of ftp to the outside ${fwcmd} add pass tcp from any to any 21 out via ${oif} setup keep-state #${fwcmd} add pass tcp from any to any 49152-65535 out via ${oif} setup keep-state # Allow setup of pop to the outside (my isp 1) ${fwcmd} add pass tcp from any to any 110 out via ${oif} setup keep-state # Allow setup of smtp to the outside (isp 1) ${fwcmd} add pass tcp from any to any 25 out via ${oif} setup keep-state # Allow setup of news to the outside ${fwcmd} add pass tcp from any to any 119 out via ${oif} setup keep-state # Allow setup of time to the outside ${fwcmd} add pass tcp from any to any 37 out via ${oif} setup keep-state # Allow DNS queries out to my ISP's DNSs ${fwcmd} add pass udp from any to any 53 out via ${oif} keep-state # Allow answers to DNS queries from my ISP ${fwcmd} add pass udp from any 53 to any in via ${oif} keep-state # Allow NTP queries out in the world ${fwcmd} add pass udp from any 123 to any 123 via ${oif} keep-state # Allow answers to NTP queries from my NTP server ${fwcmd} add pass udp from any 123 to any 123 in via ${oif} keep-state ################################################################################ # allow incoming connections from the internet to those specified ports # ################################################################################ # Allow access to our SSH server (which also listens on 443) ${fwcmd} add pass log tcp from any to me 22 in via ${oif} setup keep-state ${fwcmd} add pass log tcp from any to me 119 in via ${oif} setup keep-state #Allow access to ftp server (passive mode) from the internet $fwcmd add allow tcp from any to me 21 in via ${oif} keep-state $fwcmd add allow tcp from any to me 20 in via ${oif} keep-state $fwcmd add allow tcp from any to me 49152-65535 in via ${oif} keep-state # Allow access to our httpd $fwcmd add allow tcp from any to me 80 in via ${oif} keep-state $fwcmd add allow tcp from any to me 8080 in via ${oif} keep-state #Allow access to pop and sendmail $fwcmd add allow tcp from any to me 25 in via ${oif} keep-state $fwcmd add allow tcp from any to me 110 in via ${oif} keep-state #allow ident requests $fwcmd add allow tcp from any to me 113 in via ${oif} keep-state ################################################################################ # default to catch all the rest # ################################################################################ # Stop & log spoofing Attack attempts. # Examine incoming traffic for packets with both a source and destination # IP address in my local domain as per CIAC prevention alert. $fwcmd add deny log ip from me to me in via $oif # Reject peer-to-peer traffic incoming connections without logging ${fwcmd} add deny tcp from any to any 137-139 in via ${oif} ${fwcmd} add deny tcp from any to any 3306 in via ${oif} ${fwcmd} add deny tcp from any to any 6000 in via ${oif} # Reject&Log all setup of incoming connections from the outside ${fwcmd} add deny log tcp from any to any in via ${oif} setup # Reject&Log all incoming datagrams from the outside ${fwcmd} add deny log tcp from any to any in via ${oif} # Stop & log ping echo attacks # stop echo reply (ICMP type 0), and echo request (type 8). $fwcmd add deny log icmp from any to me in via $oif From owner-freebsd-net@FreeBSD.ORG Sun Oct 23 05:37:09 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 2A59716A41F for ; Sun, 23 Oct 2005 05:37:09 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id A922043D45 for ; Sun, 23 Oct 2005 05:37:08 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id 0AC9E4CA8F; Sun, 23 Oct 2005 05:37:29 +0000 (GMT) Received: from [192.168.0.3] (ppp157-158.static.internode.on.net [150.101.157.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by p4.roq.com (Postfix) with ESMTP id E2B344CCC1; Sun, 23 Oct 2005 05:37:25 +0000 (GMT) Message-ID: <435B217F.70106@roq.com> Date: Sun, 23 Oct 2005 15:37:03 +1000 From: Michael VInce User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20051019 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Volker References: <435A5D9B.7080309@vwsoft.com> <435A900C.3060602@roq.com> <435AD808.1030701@vwsoft.com> <200510230140.42154.max@love2party.net> <435ADFB5.10603@vwsoft.com> In-Reply-To: <435ADFB5.10603@vwsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Max Laier , freebsd-net@freebsd.org Subject: Re: IPSec tcp session stalling 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: Sun, 23 Oct 2005 05:37:09 -0000 I am using FAST_IPSEC on a multi subnet VPN with the guys on other side having Check Point VPN / Firewall. Its a VPN that does almost non stop usage, the people on the other side have 24 monitoring utils on it and its never had a problem. Its on 5.3 i386, and I fear to upgrade it, when it comes to VPN I believe in the rule if its not broke don't fix it. When I think about if I haven't had much luck when trying regular IPSEC despite docs saying its better supported? But then again I never gave it a good shot, FAST_IPSEC just sounded 'faster' Mike Volker wrote: >Max & Co: > >I've just seen I'm using kernel config 'options IPSEC' on both machines. >Should I try 'options FAST_IPSEC'? Would take some hours for kernel >recompile. Does the code IPSEC / FAST_IPSEC make a difference (even >while having not hardware crypto accelerator)? > >May I use FAST_IPSEC even without any hw-crypto devices? While reading >`man fast_ipsec' I would think it depends on a hw-crypto device... > >Please tell me if we should check IPSEC / FAST_IPSEC and I'll start a >recompile. > >Volker > > >On 2005-10-23 00:40, Max Laier wrote: > > >>To try something else: Could you guys try to disable SACK on the machines >>involved? I haven't looked at the dumps as of yet, but that's one simple >>test that might help to identify the problem. >> >>sysctl net.inet.tcp.sack.enable=0 >> >>On Sunday 23 October 2005 02:23, Volker wrote: >> >> >> >>>Michael, >>> >>>I not that sure if I'm right in checking what you suggested but when >>>trying to do ping hostB from hostA with oversized packets through the >>>IPSec tunnel by: >>> >>># ping -c 10 -s 12000 10.128.6.1 >>> >>>I'm getting replies easily. >>> >>>While doing that and tcpdump'ing the gif interface, I'm seeing the >>>fragmented packets coming in properly. >>> >>>If that's a reliable check for MTU than the problem should not be MTU >>>related. Is there any other way to check MTU problems by using `ping'? >>> >>>Thanks, >>> >>>Volker >>> >>>On 2005-10-22 20:16, Michael VInce wrote: >>> >>> >>> >>>>Try sending different sized pings or other packet size control utils to >>>>really make sure its not MTU related. >>>>Maybe there is an upstream router thats blocking ICMP fragment packets, >>>>have you ever seen them? try forcing the creation of some. >>>> >>>>Mike >>>> >>>>Volker wrote: >>>> >>>> >>>> >>>>>Still having the same problem with an IPSec tunnel between FreeBSD 5.4R >>>>>hosts. >>>>> >>>>>Problem description: >>>>>scp session tries to transfer a large file through an IPSec tunnel. The >>>>>file is being transmitted but scp says 'stalled' after 56K (49152 bytes >>>>>file size). The IPSec tunnel itself is still up even after the scp >>>>>abort. Other tcp sessions break, too when sending too much traffic >>>>>through the tunnel. >>>>> >>>>>I've taken a closer look to it and tried to get something useful out of >>>>>the tcpdump but I'm unable to see any errors or I'm misinterpreting >>>>>something. >>>>> >>>>>The connection looks like: >>>>> >>>>>extIP: A.B.C.D >>>>>extIP: E.F.G.H >>>>>host A ------------------ (internet) ------------------ host B >>>>>tunnelIP: 10.128.1.6 tunnelIP: >>>>>10.128.6.1 >>>>> >>>>>host A just has an external interface (em1) connected to a leased line >>>>>with a fixed IP address (IP-addr A.B.C.D). >>>>>host B has an S-DSL connection at xl0, PPPoE at ng0 (IP-addr. E.F.G.H). >>>>> >>>>>Both hosts are using gif for the IPSec tunnel. >>>>> >>>>>The routing tables (netstat -rnWf inet) are looking good and IMHO the >>>>>MTU is fine. >>>>> >>>>>host A: >>>>>em1: flags=8843 mtu 1500 >>>>> options=b >>>>> inet A.B.C.D netmask 0xfffffff8 broadcast A.B.C.z >>>>> ether 00:c0:9f:46:ec:c7 >>>>> media: Ethernet autoselect (100baseTX ) >>>>> status: active >>>>>gif6: flags=8051 mtu 1280 >>>>> tunnel inet A.B.C.D --> E.F.G.H >>>>> inet 10.128.1.6 --> 10.128.6.1 netmask 0xffffffff >>>>> inet6 fe80::2c0:9fff:fe46:ecc6%gif6 prefixlen 64 scopeid 0x4 >>>>> >>>>>Routing tables (shortened) >>>>>Destination Gateway Flags Refs Use Mtu >>>>>Netif Expire >>>>>default A.B.C.x UGS 2 516686 1500 em1 >>>>>10.128.1.6 127.0.0.1 UH 0 14 >>>>>16384 lo0 >>>>>10.128.6.1 10.128.1.6 UH 0 6017 >>>>>1280 gif6 >>>>>127.0.0.1 127.0.0.1 UH 0 31633 >>>>>16384 lo0 >>>>>A.B.C.x/29 link#2 UC 0 0 1500 em1 >>>>>A.B.C.D 00:c0:9f:46:ec:c7 UHLW 0 112 1500 lo0 >>>>> >>>>>On host B the interfaces and routing tables are looking like: >>>>>xl0: flags=8843 mtu 1500 >>>>> options=8 >>>>> inet 0.0.0.0 netmask 0xff000000 broadcast 0.255.255.255 >>>>> inet6 fe80::260:8ff:fe6c:e73c%xl0 prefixlen 64 scopeid 0x1 >>>>> ether 00:60:08:6c:e7:3c >>>>> media: Ethernet 10baseT/UTP (10baseT/UTP ) >>>>> status: active >>>>>gif1: flags=8051 mtu 1280 >>>>> tunnel inet E.F.G.H --> A.B.C.D >>>>> inet6 fe80::260:8ff:fe6c:e73c%gif1 prefixlen 64 scopeid 0x4 >>>>> inet 10.128.6.1 --> 10.128.1.6 netmask 0xffffffff >>>>>ng0: flags=88d1 mtu 1456 >>>>> inet E.F.G.H --> 217.5.98.186 netmask 0xffffffff >>>>> >>>>>Routing tables (shortened) >>>>>Destination Gateway Flags Refs Use Mtu >>>>>Netif Expire >>>>>0 link#1 UC 0 0 1500 >>>>>xl0 => >>>>>default 217.5.98.186 UGS 1 38474 >>>>>1456 ng0 >>>>>10.128.1.6 10.128.6.1 UH 4 2196 >>>>>1280 gif1 >>>>>127.0.0.1 127.0.0.1 UH 0 80424 >>>>>16384 lo0 >>>>>217.5.98.186 E.F.G.H UH 1 0 1456 ng0 >>>>>E.F.G.H lo0 UHS 0 0 16384 lo0 >>>>> >>>>>While trying to fetch a file by scp on host A (receiver) from host B >>>>>(sender), I captured the following tcpdump on host B: >>>>> >>>>>tcpdump -netttvvi gif1: >>>>> >>>>> >>>>> >>>>>>000023 AF 2 1280: IP (tos 0x8, ttl 64, id 13202, offset 0, flags >>>>>>[none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>>43864:45092(1228) ack 1330 win 33156 >>>>>565002838> >>>>>>000207 AF 2 1280: IP (tos 0x8, ttl 64, id 52187, offset 0, flags >>>>>>[none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>>45092:46320(1228) ack 1330 win 33156 >>>>>565002838> >>>>>>000220 AF 2 1280: IP (tos 0x8, ttl 64, id 33774, offset 0, flags >>>>>>[none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>>46320:47548(1228) ack 1330 win 33156 >>>>>565002838> >>>>>>003524 AF 2 52: IP (tos 0x8, ttl 64, id 42063, offset 0, flags >>>>>>[none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>>>>>1330:1330(0) ack 38952 win 33156 >>>>>481770524> 000024 AF 2 1280: IP (tos 0x8, ttl 64, id 48541, offset 0, >>>>>>flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>>47548:48776(1228) ack 1330 win 33156 >>>>>565002844> >>>>>>011203 AF 2 52: IP (tos 0x8, ttl 64, id 60517, offset 0, flags >>>>>>[none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>>>>>1330:1330(0) ack 41408 win 32542 >>>>>481770530> 000058 AF 2 1280: IP (tos 0x8, ttl 64, id 15798, offset 0, >>>>>>flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>>48776:50004(1228) ack 1330 win 33156 >>>>>565002855> >>>>>>000246 AF 2 1280: IP (tos 0x8, ttl 64, id 31721, offset 0, flags >>>>>>[none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>>50004:51232(1228) ack 1330 win 33156 >>>>>565002855> >>>>>>005147 AF 2 52: IP (tos 0x8, ttl 64, id 22347, offset 0, flags >>>>>>[none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>>>>>1330:1330(0) ack 42636 win 33156 >>>>>481770542> 000024 AF 2 1280: IP (tos 0x8, ttl 64, id 61057, offset 0, >>>>>>flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>>51232:52460(1228) ack 1330 win 33156 >>>>>565002861> >>>>>>020769 AF 2 52: IP (tos 0x8, ttl 64, id 27692, offset 0, flags >>>>>>[none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>>>>>1330:1330(0) ack 45092 win 32542 >>>>>481770547> 000027 AF 2 1280: IP (tos 0x8, ttl 64, id 64167, offset 0, >>>>>>flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>>52460:53688(1228) ack 1330 win 33156 >>>>>565002881> >>>>>>000209 AF 2 1280: IP (tos 0x8, ttl 64, id 45457, offset 0, flags >>>>>>[none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>>53688:54916(1228) ack 1330 win 33156 >>>>>565002881> >>>>>>005260 AF 2 52: IP (tos 0x8, ttl 64, id 53832, offset 0, flags >>>>>>[none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>>>>>1330:1330(0) ack 46320 win 33156 >>>>>481770567> 000024 AF 2 1280: IP (tos 0x8, ttl 64, id 3515, offset 0, >>>>>>flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>>54916:56144(1228) ack 1330 win 33156 >>>>>565002887> >>>>>>011020 AF 2 52: IP (tos 0x8, ttl 64, id 11608, offset 0, flags >>>>>>[none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>>>>>1330:1330(0) ack 48776 win 32542 >>>>>481770568> 000026 AF 2 1280: IP (tos 0x8, ttl 64, id 5848, offset 0, >>>>>>flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>>56144:57372(1228) ack 1330 win 33156 >>>>>565002898> >>>>>>000211 AF 2 1280: IP (tos 0x8, ttl 64, id 39892, offset 0, flags >>>>>>[none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>>57372:58600(1228) ack 1330 win 33156 >>>>>565002898> >>>>>>005641 AF 2 52: IP (tos 0x8, ttl 64, id 7943, offset 0, flags >>>>>>[none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>>>>>1330:1330(0) ack 50004 win 33156 >>>>>481770582> 000024 AF 2 1280: IP (tos 0x8, ttl 64, id 8678, offset 0, >>>>>>flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>>58600:59828(1228) ack 1330 win 33156 >>>>>565002904> >>>>>>011072 AF 2 52: IP (tos 0x8, ttl 64, id 38257, offset 0, flags >>>>>>[none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>>>>>1330:1330(0) ack 52460 win 32542 >>>>>481770583> 000025 AF 2 1280: IP (tos 0x8, ttl 64, id 12255, offset 0, >>>>>>flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>>59828:61056(1228) ack 1330 win 33156 >>>>>565002915> >>>>>>000209 AF 2 1280: IP (tos 0x8, ttl 64, id 46257, offset 0, flags >>>>>>[none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>>61056:62284(1228) ack 1330 win 33156 >>>>>565002915> >>>>>>000222 AF 2 1280: IP (tos 0x8, ttl 64, id 4093, offset 0, flags >>>>>>[none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>>62284:63512(1228) ack 1330 win 33156 >>>>>565002915> >>>>>>007065 AF 2 52: IP (tos 0x8, ttl 64, id 18720, offset 0, flags >>>>>>[none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>>>>>1330:1330(0) ack 53688 win 33156 >>>>>481770609> 000025 AF 2 1280: IP (tos 0x8, ttl 64, id 38378, offset 0, >>>>>>flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>>63512:64740(1228) ack 1330 win 33156 >>>>>565002922> >>>>>>011034 AF 2 52: IP (tos 0x8, ttl 64, id 18718, offset 0, flags >>>>>>[none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>>>>>1330:1330(0) ack 56144 win 32542 >>>>>481770609> 000024 AF 2 1280: IP (tos 0x8, ttl 64, id 8148, offset 0, >>>>>>flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>>64740:65968(1228) ack 1330 win 33156 >>>>>565002934> >>>>>>005991 AF 2 52: IP (tos 0x8, ttl 64, id 62285, offset 0, flags >>>>>>[none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>>>>>1330:1330(0) ack 57372 win 33156 >>>>>481770625> 010726 AF 2 52: IP (tos 0x8, ttl 64, id 1549, offset 0, >>>>>>flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum >>>>>>ok] 1330:1330(0) ack 59828 win 32542 >>>>>481770625> 005670 AF 2 52: IP (tos 0x8, ttl 64, id 61504, offset 0, >>>>>>flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum >>>>>>ok] 1330:1330(0) ack 61056 win 33156 >>>>>481770642> 011260 AF 2 52: IP (tos 0x8, ttl 64, id 32633, offset 0, >>>>>>flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum >>>>>>ok] 1330:1330(0) ack 63512 win 32542 >>>>>481770642> 005510 AF 2 52: IP (tos 0x8, ttl 64, id 54614, offset 0, >>>>>>flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum >>>>>>ok] 1330:1330(0) ack 64740 win 33156 >>>>>481770650> 104909 AF 2 52: IP (tos 0x8, ttl 64, id 50471, offset 0, >>>>>>flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum >>>>>>ok] 1330:1330(0) ack 65968 win 33156 >>>>>481770661> >>>>>> >>>>>> >>>>>tcpdump -netttvvi ng0 host A.B.C.D: >>>>> >>>>> >>>>> >>>>>>000227 AF 2 1352: IP (tos 0x8, ttl 64, id 25895, offset 0, flags >>>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x10b) >>>>>>011042 AF 2 128: IP (tos 0x8, ttl 61, id 5786, offset 0, flags >>>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf0) >>>>>>000226 AF 2 1352: IP (tos 0x8, ttl 64, id 36701, offset 0, flags >>>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x10c) >>>>>>000216 AF 2 1352: IP (tos 0x8, ttl 64, id 8789, offset 0, flags >>>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x10d) >>>>>>004853 AF 2 128: IP (tos 0x8, ttl 61, id 17128, offset 0, flags >>>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf1) >>>>>>000227 AF 2 1352: IP (tos 0x8, ttl 64, id 34888, offset 0, flags >>>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x10e) >>>>>>018747 AF 2 128: IP (tos 0x8, ttl 61, id 14828, offset 0, flags >>>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf2) >>>>>>000248 AF 2 1352: IP (tos 0x8, ttl 64, id 34356, offset 0, flags >>>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x10f) >>>>>>000223 AF 2 1352: IP (tos 0x8, ttl 64, id 34151, offset 0, flags >>>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x110) >>>>>>005030 AF 2 128: IP (tos 0x8, ttl 61, id 45476, offset 0, flags >>>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf3) >>>>>>000228 AF 2 1352: IP (tos 0x8, ttl 64, id 39765, offset 0, flags >>>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x111) >>>>>>011247 AF 2 128: IP (tos 0x8, ttl 61, id 63692, offset 0, flags >>>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf4) >>>>>>000226 AF 2 1352: IP (tos 0x8, ttl 64, id 29240, offset 0, flags >>>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x112) >>>>>>000222 AF 2 1352: IP (tos 0x8, ttl 64, id 43306, offset 0, flags >>>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x113) >>>>>>005663 AF 2 128: IP (tos 0x8, ttl 61, id 32980, offset 0, flags >>>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf5) >>>>>>000228 AF 2 1352: IP (tos 0x8, ttl 64, id 56920, offset 0, flags >>>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x114) >>>>>>010190 AF 2 128: IP (tos 0x8, ttl 61, id 3206, offset 0, flags >>>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf6) >>>>>>000227 AF 2 1352: IP (tos 0x8, ttl 64, id 4655, offset 0, flags >>>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x115) >>>>>>000215 AF 2 1352: IP (tos 0x8, ttl 64, id 62740, offset 0, flags >>>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x116) >>>>>>000203 AF 2 1352: IP (tos 0x8, ttl 64, id 35642, offset 0, flags >>>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x117) >>>>>>006875 AF 2 128: IP (tos 0x8, ttl 61, id 37801, offset 0, flags >>>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf7) >>>>>>000234 AF 2 1352: IP (tos 0x8, ttl 64, id 41803, offset 0, flags >>>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x118) >>>>>>010651 AF 2 128: IP (tos 0x8, ttl 61, id 54256, offset 0, flags >>>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf8) >>>>>>000235 AF 2 1352: IP (tos 0x8, ttl 64, id 30732, offset 0, flags >>>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x119) >>>>>>007913 AF 2 128: IP (tos 0x8, ttl 61, id 7647, offset 0, flags >>>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf9) >>>>>>011166 AF 2 128: IP (tos 0x8, ttl 61, id 58037, offset 0, flags >>>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xfa) >>>>>>005483 AF 2 128: IP (tos 0x8, ttl 61, id 65275, offset 0, flags >>>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xfb) >>>>>>011250 AF 2 128: IP (tos 0x8, ttl 61, id 47289, offset 0, flags >>>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xfc) >>>>>>005505 AF 2 128: IP (tos 0x8, ttl 61, id 203, offset 0, flags >>>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xfd) >>>>>>104747 AF 2 128: IP (tos 0x8, ttl 61, id 45263, offset 0, flags >>>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xfe) >>>>>>8. 338674 AF 2 128: IP (tos 0x8, ttl 61, id 36351, offset 0, flags >>>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xff) >>>>>>319992 AF 2 128: IP (tos 0x8, ttl 61, id 18085, offset 0, flags >>>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x100) >>>>>>441837 AF 2 128: IP (tos 0x8, ttl 61, id 58323, offset 0, flags >>>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x101) >>>>>>684077 AF 2 128: IP (tos 0x8, ttl 61, id 35487, offset 0, flags >>>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x102) >>>>>>1. 167602 AF 2 128: IP (tos 0x8, ttl 61, id 34442, offset 0, flags >>>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x103) >>>>>>2. 136032 AF 2 128: IP (tos 0x8, ttl 61, id 8345, offset 0, flags >>>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x104) >>>>>>2. 984665 AF 2 128: IP (tos 0x8, ttl 61, id 35456, offset 0, flags >>>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x105) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>From what I'm seeing host B just stops sending without any reason. At >>>>> >>>>>least I don't see any fragmented packets. The only thing I've seen is >>>>>some packets doesn't get ack'ed by the receiver. >>>>> >>>>>These packets never get ack'ed: >>>>>46320:47548(1228) >>>>>50004:51232(1228) >>>>>53688:54916(1228) >>>>>57372:58600(1228) >>>>>61056:62284(1228) >>>>> >>>>>On host A I dumped the following: >>>>> >>>>>tcpdump -netttvvi gif6 >>>>> >>>>> >>>>> >>>>> >>>>>>1129985378.941282 AF 2 52: IP (tos 0x8, ttl 64, id 41637, offset 0, >>>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>>sum ok] 1330:1330(0) ack 45092 win 32542 >>>>>490857876> >>>>>>1129985378.952628 AF 2 1280: IP (tos 0x8, ttl 64, id 14004, offset >>>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>>45092:46320(1228) ack 1330 win 33156 >>>>>574090210> >>>>>>1129985378.952657 AF 2 52: IP (tos 0x8, ttl 64, id 23243, offset 0, >>>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>>sum ok] 1330:1330(0) ack 46320 win 33156 >>>>>490857901> >>>>>>1129985378.958250 AF 2 1280: IP (tos 0x8, ttl 64, id 4306, offset 0, >>>>>>flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>>46320:47548(1228) ack 1330 win 33156 >>>>>574090210> >>>>>>1129985378.971118 AF 2 1280: IP (tos 0x8, ttl 64, id 33534, offset >>>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>>47548:48776(1228) ack 1330 win 33156 >>>>>574090229> >>>>>>1129985378.971137 AF 2 52: IP (tos 0x8, ttl 64, id 60095, offset 0, >>>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>>sum ok] 1330:1330(0) ack 48776 win 32542 >>>>>490857901> >>>>>>1129985378.982488 AF 2 1280: IP (tos 0x8, ttl 64, id 11459, offset >>>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>>48776:50004(1228) ack 1330 win 33156 >>>>>574090240> >>>>>>1129985378.982516 AF 2 52: IP (tos 0x8, ttl 64, id 33184, offset 0, >>>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>>sum ok] 1330:1330(0) ack 50004 win 33156 >>>>>490857931> >>>>>>1129985378.987989 AF 2 1280: IP (tos 0x8, ttl 64, id 54180, offset >>>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>>50004:51232(1228) ack 1330 win 33156 >>>>>574090240> >>>>>>1129985378.994231 AF 2 1280: IP (tos 0x8, ttl 64, id 24535, offset >>>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>>51232:52460(1228) ack 1330 win 33156 >>>>>574090251> >>>>>>1129985378.994250 AF 2 52: IP (tos 0x8, ttl 64, id 30647, offset 0, >>>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>>sum ok] 1330:1330(0) ack 52460 win 32542 >>>>>490857931> >>>>>>1129985379.012101 AF 2 1280: IP (tos 0x8, ttl 64, id 61397, offset >>>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>>52460:53688(1228) ack 1330 win 33156 >>>>>574090270> >>>>>>1129985379.012132 AF 2 52: IP (tos 0x8, ttl 64, id 60550, offset 0, >>>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>>sum ok] 1330:1330(0) ack 53688 win 33156 >>>>>490857960> >>>>>>1129985379.017754 AF 2 1280: IP (tos 0x8, ttl 64, id 28408, offset >>>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>>53688:54916(1228) ack 1330 win 33156 >>>>>574090270> >>>>>>1129985379.023720 AF 2 1280: IP (tos 0x8, ttl 64, id 27558, offset >>>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>>54916:56144(1228) ack 1330 win 33156 >>>>>574090281> >>>>>>1129985379.023741 AF 2 52: IP (tos 0x8, ttl 64, id 21502, offset 0, >>>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>>sum ok] 1330:1330(0) ack 56144 win 32542 >>>>>490857961> >>>>>>1129985379.035333 AF 2 1280: IP (tos 0x8, ttl 64, id 18885, offset >>>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>>56144:57372(1228) ack 1330 win 33156 >>>>>574090293> >>>>>>1129985379.035362 AF 2 52: IP (tos 0x8, ttl 64, id 59875, offset 0, >>>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>>sum ok] 1330:1330(0) ack 57372 win 33156 >>>>>490857984> >>>>>>1129985379.040830 AF 2 1280: IP (tos 0x8, ttl 64, id 37252, offset >>>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>>57372:58600(1228) ack 1330 win 33156 >>>>>574090293> >>>>>>1129985379.046576 AF 2 1280: IP (tos 0x8, ttl 64, id 18349, offset >>>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>>58600:59828(1228) ack 1330 win 33156 >>>>>574090293> >>>>>>1129985379.046595 AF 2 52: IP (tos 0x8, ttl 64, id 43697, offset 0, >>>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>>sum ok] 1330:1330(0) ack 59828 win 32542 >>>>>490857984> >>>>>>1129985379.064961 AF 2 1280: IP (tos 0x8, ttl 64, id 38300, offset >>>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>>59828:61056(1228) ack 1330 win 33156 >>>>>574090322> >>>>>>1129985379.064993 AF 2 52: IP (tos 0x8, ttl 64, id 47539, offset 0, >>>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>>sum ok] 1330:1330(0) ack 61056 win 33156 >>>>>490858013> >>>>>>1129985379.070688 AF 2 1280: IP (tos 0x8, ttl 64, id 30345, offset >>>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>>61056:62284(1228) ack 1330 win 33156 >>>>>574090322> >>>>>>1129985379.076184 AF 2 1280: IP (tos 0x8, ttl 64, id 37536, offset >>>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>>62284:63512(1228) ack 1330 win 33156 >>>>>574090322> >>>>>>1129985379.076202 AF 2 52: IP (tos 0x8, ttl 64, id 34201, offset 0, >>>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>>sum ok] 1330:1330(0) ack 63512 win 32542 >>>>>490858013> >>>>>>1129985379.081680 AF 2 1280: IP (tos 0x8, ttl 64, id 20637, offset >>>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>>63512:64740(1228) ack 1330 win 33156 >>>>>574090334> >>>>>>1129985379.081709 AF 2 52: IP (tos 0x8, ttl 64, id 59866, offset 0, >>>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>>sum ok] 1330:1330(0) ack 64740 win 33156 >>>>>490858025> >>>>>>1129985379.087678 AF 2 1280: IP (tos 0x8, ttl 64, id 35213, offset >>>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>>64740:65968(1228) ack 1330 win 33156 >>>>>574090345> >>>>>>1129985379.186906 AF 2 52: IP (tos 0x8, ttl 64, id 2465, offset 0, >>>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>>sum ok] 1330:1330(0) ack 65968 win 33156 >>>>>490858036> >>>>>> >>>>>> >>>>>tcpdump -netttvvi em1 host E.F.G.H >>>>> >>>>> >>>>> >>>>> >>>>>>1129985379.064825 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype >>>>>>IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 45003, offset 0, >>>>>>flags [none], length: 1352) E.F.G.H > A.B.C.D: >>>>>>ESP(spi=0x0e0dffaa,seq=0x3e) >>>>>>1129985379.065024 00:c0:9f:46:ec:c7 > 00:13:c4:fa:6c:20, ethertype >>>>>>IPv4 (0x0800), length 142: IP (tos 0x8, ttl 64, id 1195, offset 0, >>>>>>flags [none], length: 128) A.B.C.D > E.F.G.H: >>>>>>ESP(spi=0x029a41b4,seq=0x2f) >>>>>>1129985379.070572 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype >>>>>>IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 36820, offset 0, >>>>>>flags [none], length: 1352) E.F.G.H > A.B.C.D: >>>>>>ESP(spi=0x0e0dffaa,seq=0x3f) >>>>>>1129985379.076069 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype >>>>>>IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 44971, offset 0, >>>>>>flags [none], length: 1352) E.F.G.H > A.B.C.D: >>>>>>ESP(spi=0x0e0dffaa,seq=0x40) >>>>>>1129985379.076233 00:c0:9f:46:ec:c7 > 00:13:c4:fa:6c:20, ethertype >>>>>>IPv4 (0x0800), length 142: IP (tos 0x8, ttl 64, id 56964, offset 0, >>>>>>flags [none], length: 128) A.B.C.D > E.F.G.H: >>>>>>ESP(spi=0x029a41b4,seq=0x30) >>>>>>1129985379.081565 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype >>>>>>IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 24742, offset 0, >>>>>>flags [none], length: 1352) E.F.G.H > A.B.C.D: >>>>>>ESP(spi=0x0e0dffaa,seq=0x41) >>>>>>1129985379.081741 00:c0:9f:46:ec:c7 > 00:13:c4:fa:6c:20, ethertype >>>>>>IPv4 (0x0800), length 142: IP (tos 0x8, ttl 64, id 9390, offset 0, >>>>>>flags [none], length: 128) A.B.C.D > E.F.G.H: >>>>>>ESP(spi=0x029a41b4,seq=0x31) >>>>>>1129985379.087562 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype >>>>>>IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 48065, offset 0, >>>>>>flags [none], length: 1352) E.F.G.H > A.B.C.D: >>>>>>ESP(spi=0x0e0dffaa,seq=0x42) >>>>>>1129985379.186945 00:c0:9f:46:ec:c7 > 00:13:c4:fa:6c:20, ethertype >>>>>>IPv4 (0x0800), length 142: IP (tos 0x8, ttl 64, id 36315, offset 0, >>>>>>flags [none], length: 128) A.B.C.D > E.F.G.H: >>>>>>ESP(spi=0x029a41b4,seq=0x32) >>>>>> >>>>>> >>>>>If I'm not misleaded, this also doesn't show any errors except the >>>>>missing ack's. host B just stops sending. If there's an ack missing, >>>>>doesn't have the sending host to just repeat the un-ack'ed packet? >>>>> >>>>>The IPSec tunnel does not die. Even shortly after the (scp) transfer >>>>>stalls the tunnel itself is still usable (for small amounts of data). To >>>>>make it more worse, when disabling pf at the senders side, the transfer >>>>>works. I've tripple checked pflog for denied packets on both sides but >>>>>pf didn't filter any packets out. >>>>> >>>>>When disabling the IPSec rules using `setkey -F; setkey -FP' on the >>>>>tunnel for a moment, the scp transfer does not stall. So it's not a gif >>>>>issue. >>>>> >>>>>It doesn't seem to be an MTU issue (pf has also the rule 'scrub in/out >>>>>all no-df'), but what kind of issue is that?? Has anybody ever >>>>>experienced similar things? Or am I misinterpreting the tcpdump output? >>>>> >>>>> >>>>>Any help and hint is appreciated! Without an error message I'm lost. >>>>> >>>>>Volker >>>>> >>>>>_______________________________________________ >>>>>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" >>>>> >>>>> >>>_______________________________________________ >>>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 Sun Oct 23 07:24:08 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 F3EFD16A41F; Sun, 23 Oct 2005 07:24:07 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AE0B43D46; Sun, 23 Oct 2005 07:24:07 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id DC2DF4CC15; Sun, 23 Oct 2005 07:24:27 +0000 (GMT) Received: from [192.168.0.3] (ppp157-158.static.internode.on.net [150.101.157.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by p4.roq.com (Postfix) with ESMTP id 460444CC12; Sun, 23 Oct 2005 07:24:25 +0000 (GMT) Message-ID: <435B3A92.1040600@roq.com> Date: Sun, 23 Oct 2005 17:24:02 +1000 From: Michael VInce User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20051019 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gleb Smirnoff References: <20051020140200.GL59364@cell.sick.ru> <4359FFE3.7060001@roq.com> <20051022091905.GH59364@cell.sick.ru> In-Reply-To: <20051022091905.GH59364@cell.sick.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: net@FreeBSD.org Subject: Re: em(4) patch for test 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: Sun, 23 Oct 2005 07:24:08 -0000 Here is my second round of my non scientific benchmarking and tests, I hope this is useful. I been having fun benchmarking these machines but I am starting to get sick of it as well :) but I find it important to know that things are going to work right when they are launched to do their real work. The final results look good after patching and running ab tests I was unable to get errors out of netstat -i output, even when grilling the server-C machine to a rather high load. #################### Test 1 (Non patched) #################### netperf test, non patched machines. load results below with top -S, no Ierrs or Oerrs. A> /usr/local/netperf/netperf -l 60 -H server-C -t TCP_STREAM -i 10,2 -I 99,5 -- -m 4096 -s 57344 -S 57344 Server-C load snap shot last pid: 1644; load averages: 0.94, 0.48, 0.23 up 0+06:30:41 12:29:59 239 processes: 7 running, 130 sleeping, 102 waiting CPU states: 0.5% user, 0.0% nice, 2.3% system, 9.4% interrupt, 87.9% idle Mem: 125M Active, 1160M Inact, 83M Wired, 208K Cache, 112M Buf, 1893M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 13 root 1 171 52 0K 8K CPU1 0 0:00 99.02% idle: cpu1 14 root 1 171 52 0K 8K RUN 0 386:01 98.97% idle: cpu0 12 root 1 171 52 0K 8K CPU2 2 389:02 97.75% idle: cpu2 11 root 1 171 52 0K 8K RUN 3 385:10 61.87% idle: cpu3 62 root 1 -68 -187 0K 8K WAIT 3 1:03 14.16% irq64: em0 112 root 1 -44 -163 0K 8K CPU2 3 1:35 11.23% swi1: net 1644 root 1 4 0 1640K 1016K sbwait 3 0:09 7.25% netserver 30 root 1 -64 -183 0K 8K CPU3 3 0:19 2.15% irq16: uhci0 Server-A load snap shot last pid: 1550; load averages: 0.34, 0.32, 0.21 up 0+07:28:38 12:41:33 134 processes: 3 running, 52 sleeping, 78 waiting, 1 lock CPU states: 0.8% user, 0.0% nice, 10.2% system, 42.1% interrupt, 47.0% idle Mem: 13M Active, 27M Inact, 70M Wired, 24K Cache, 213M Buf, 1810M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 11 root 1 171 52 0K 16K RUN 438:50 54.98% idle 83 root 1 -44 -163 0K 16K WAIT 2:41 17.63% swi1: net 59 root 1 -68 -187 0K 16K RUN 1:48 11.23% irq64: em2 1547 root 1 4 0 3812K 1356K sbwait 0:17 8.84% netperf 27 root 1 -68 -187 0K 16K *Giant 0:51 2.78% irq16: em0 uhci0 #################### Test 2 (Non patched) #################### On the Apache beat up test with: A> 'ab -k -n 25500 -c 900 http://server-c/338kbyte.file' You can see some error output from netstat -i on both machines, C> netstat -i | egrep 'Name|em0.*Link' Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll em0 1500 00:14:22:12:4c:03 85133828 2079 63248162 0 0 top highest load. last pid: 2170; load averages: 35.56, 16.54, 8.52 up 0+07:28:47 13:28:05 1182 processes:125 running, 954 sleeping, 103 waiting CPU states: 5.4% user, 0.0% nice, 37.2% system, 32.4% interrupt, 25.0% idle Mem: 372M Active, 1161M Inact, 131M Wired, 208K Cache, 112M Buf, 1595M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 13 root 1 171 52 0K 8K CPU1 0 0:00 100.00% idle: cpu1 62 root 1 -68 -187 0K 8K WAIT 3 5:57 89.79% irq64: em0 30 root 1 -64 -183 0K 8K CPU0 0 2:11 36.08% irq16: uhci0 12 root 1 171 52 0K 8K RUN 2 439:16 2.98% idle: cpu2 14 root 1 171 52 0K 8K RUN 0 435:36 2.98% idle: cpu0 11 root 1 171 52 0K 8K RUN 3 430:35 2.98% idle: cpu3 2146 root 1 -8 0 4060K 2088K piperd 2 0:01 0.15% rotatelogs 129 root 1 20 0 0K 8K syncer 0 0:08 0.05% syncer 112 root 1 -44 -163 0K 8K WAIT 0 4:50 0.00% swi1: net 110 root 1 -32 -151 0K 8K WAIT 3 1:05 0.00% swi4: clock sio 2149 www 66 113 0 44476K 31276K RUN 3 0:08 0.00% httpd Server-A netstat and highest top. (non patched) A> netstat -i | egrep 'em2.*Link|Name' Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll em2 1500 00:14:22:15:ff:8e 61005124 690 84620697 0 0 last pid: 1698; load averages: 0.65, 0.29, 0.13 up 0+08:15:10 13:28:05 136 processes: 6 running, 53 sleeping, 76 waiting, 1 lock CPU states: 3.4% user, 0.0% nice, 58.6% system, 32.0% interrupt, 6.0% idle Mem: 21M Active, 27M Inact, 71M Wired, 36K Cache, 213M Buf, 1793M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 1698 root 1 112 0 24800K 9136K RUN 0:39 61.61% ab 83 root 1 -44 -163 0K 16K RUN 4:07 13.38% swi1: net 59 root 1 -68 -187 0K 16K RUN 2:44 11.04% irq64: em2 11 root 1 171 52 0K 16K RUN 479:02 8.79% idle 27 root 1 -68 -187 0K 16K *Giant 1:16 3.03% irq16: em0 uhci0 84 root 1 -32 -151 0K 16K RUN 0:22 0.00% swi4: clock sio While we are at it, the apache2 server-status results Server uptime: 1 minute Total accesses: 17179 - Total Traffic: 5.4 GB CPU Usage: u17.2734 s80.8672 cu0 cs0 - 164% CPU load 286 requests/sec - 92.2 MB/second - 329.9 kB/request 901 requests currently being processed, 379 idle workers Looking at those Apache results show its serving ability must be partly just bandwidth limited at around 900mbits/sec or 92megabytes/sec mark, I should probably test with smaller files, to test its ability of handling more requests at the same time. It appears (but really just guessing) that at least some of the errors out of netstat -i is when apache is not configured properly and its failing to hand out requests and on the client side with ab, it spits back these apr_connect(): Invalid argument (22). ### Patched Results, both machines A (client) and C (server) had the patched em driver. #################### Test 1 (Patched) #################### A> /usr/local/netperf/netperf -l 360 -H server-C -t TCP_STREAM -i 10,2 -I 99,5 -- -m 4096 -s 57344 -S 57344 Server-C load snap shot last pid: 1905; load averages: 0.63, 0.43, 0.20 up 0+08:49:40 23:11:02 239 processes: 6 running, 130 sleeping, 103 waiting CPU states: 0.1% user, 0.0% nice, 3.0% system, 5.3% interrupt, 91.6% idle Mem: 121M Active, 25M Inact, 80M Wired, 960K Cache, 68M Buf, 3033M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 13 root 1 171 52 0K 8K CPU1 0 0:00 99.02% idle: cpu1 14 root 1 171 52 0K 8K RUN 0 524:16 98.29% idle: cpu0 12 root 1 171 52 0K 8K RUN 2 528:10 98.10% idle: cpu2 11 root 1 171 52 0K 8K RUN 3 526:49 57.42% idle: cpu3 62 root 1 -68 -187 0K 8K WAIT 3 0:40 14.70% irq64: em0 112 root 1 -44 -163 0K 8K WAIT 2 0:51 12.35% swi1: net 1885 root 1 4 0 1520K 960K sbwait 2 0:26 9.28% netserver 30 root 1 -64 -183 0K 8K RUN 3 0:11 2.73% irq16: uhci0 Server-A load snap shot last pid: 1690; load averages: 0.43, 0.31, 0.14 up 0+08:49:30 23:11:06 132 processes: 3 running, 50 sleeping, 78 waiting, 1 lock CPU states: 0.0% user, 0.0% nice, 7.1% system, 35.3% interrupt, 57.5% idle Mem: 10M Active, 6896K Inact, 24M Wired, 4K Cache, 9072K Buf, 1930M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 11 root 1 171 52 0K 16K RUN 525:59 54.15% idle 83 root 1 -44 -163 0K 16K WAIT 0:59 17.04% swi1: net 59 root 1 -68 -187 0K 16K RUN 0:34 11.33% irq64: em2 1674 root 1 4 0 3812K 1356K sbwait 0:21 9.03% netperf 27 root 1 -68 -187 0K 16K *Giant 0:15 3.81% irq16: em0 uhci0 No errors for netstat -i created on netperf tests. netstat -i | egrep 'Name|em0.*Link' Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll em0 1500 00:14:22:12:4c:03 23889010 0 14542263 0 0 #################### Test 2 (Patched) #################### Apache ab test ( with: A> 'ab -k -n 25500 -c 900 http://server-c/338kbyte.file' ) Server-C load snap shot last pid: 2004; load averages: 35.26, 10.84, 4.23 up 0+08:59:39 23:21:01 1184 processes:137 running, 946 sleeping, 101 waiting CPU states: 7.9% user, 0.0% nice, 37.8% system, 29.3% interrupt, 25.0% idle Mem: 418M Active, 25M Inact, 106M Wired, 960K Cache, 71M Buf, 2711M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 13 root 1 171 52 0K 8K CPU1 0 0:00 99.02% idle: cpu1 112 root 1 -44 -163 0K 8K CPU3 3 2:08 62.26% swi1: net 62 root 1 -68 -187 0K 8K WAIT 3 1:36 42.53% irq64: em0 30 root 1 -64 -183 0K 8K CPU0 3 0:24 5.96% irq16: uhci0 11 root 1 171 52 0K 8K RUN 3 534:13 3.17% idle: cpu3 12 root 1 171 52 0K 8K RUN 2 536:57 3.03% idle: cpu2 14 root 1 171 52 0K 8K RUN 0 532:58 3.03% idle: cpu0 1980 root 1 -8 0 4060K 2088K piperd 2 0:01 0.30% rotatelogs Server-A load snap shot last pid: 1700; load averages: 0.66, 0.30, 0.20 up 0+08:59:30 23:21:06 132 processes: 5 running, 49 sleeping, 77 waiting, 1 lock CPU states: 3.8% user, 0.0% nice, 61.7% system, 34.6% interrupt, 0.0% idle Mem: 17M Active, 6932K Inact, 24M Wired, 4K Cache, 9440K Buf, 1921M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 1700 root 1 118 0 25020K 9172K RUN 0:42 62.70% ab 83 root 1 -44 -163 0K 16K RUN 1:54 16.06% swi1: net 59 root 1 -68 -187 0K 16K RUN 1:07 12.79% irq64: em2 11 root 1 171 52 0K 16K RUN 533:11 3.56% idle 27 root 1 -68 -187 0K 16K *Giant 0:29 3.03% irq16: em0 uhci0 Interestingly there were no errors this time from the ab tests A> netstat -i | egrep 'em2.*Link|Name' Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll em2 1500 00:14:ff:15:fe:8e 24573749 0 35135895 0 0 C> netstat -i | egrep 'Name|em0.*Link' Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll em0 1500 00:14:ff:12:4k:03 35135932 0 24572541 0 0 Maybe it was another luck of the draw test for the patched em driver but I got higher speeds according to the Apache server-status and 'ab' stats. Also note that with some of the tests I was posting earlier this week I was running apache 2.054 worker mode, now I am on 2.0.55 worker mode and I appear to be getting faster speeds from this version, if it was my apache that just needed a restart or its the new build I don't know ( the down side of not doing lab strict enough benchmarking) Snap shot of 'server-status' Restart Time: Saturday, 22-Oct-2005 23:19:55 PDT Parent Server Generation: 0 Server uptime: 1 minute 1 second Total accesses: 20668 - Total Traffic: 6.5 GB CPU Usage: u21.0469 s87.8828 cu0 cs0 - 179% CPU load 339 requests/sec - 109.2 MB/second - 330.0 kB/request 901 requests currently being processed, 379 idle workers Pushed 109megs/sec over 6.5gig traffic in 1 minute. Here are the ab client side results Concurrency Level: 900 Time taken for tests: 75.783501 seconds Complete requests: 25500 Failed requests: 0 Write errors: 0 Keep-Alive requests: 25500 Total transferred: 8784117972 bytes HTML transferred: 8776728432 bytes Requests per second: 336.48 [#/sec] (mean) Time per request: 2674.712 [ms] (mean) Time per request: 2.972 [ms] (mean, across all concurrent requests) Transfer rate: 113194.03 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 13 199.1 0 6207 Processing: 52 2601 1512.4 2313 20428 Waiting: 1 173 632.8 22 7090 Total: 52 2615 1543.0 2315 20428 I did watch the gateway (B) pf state table and did an ab test with and without pf running, I didn't see any difference in results when having pf running with stateful rules, ab's Time per requests stayed low and transfer rates stayed high. Most of the time the total states were exactly 900 (plus 1 for ssh session) which would make sense considering the 900 keep-alive concurrency level on the ab test. pftop output RULE ACTION DIR LOG Q IF PR K PKTS BYTES STATES MAX INFO 0 Pass In Q em2 tcp M 37362067 1856847K 901 inet from any to server-c port = http In frustration of not getting any errors I ran ab for longer doing 50000 requests to push server-c into an even higher load (45.68) , but I still didnt get any errors out of netstat -i ab -k -n 50000 -c 900 http://server-c/338kbyte.file Server-C load snap shot. last pid: 2274; load averages: 45.68, 27.33, 13.88 up 0+09:36:38 23:58:00 1202 processes:151 running, 951 sleeping, 100 waiting CPU states: 7.1% user, 0.0% nice, 37.2% system, 30.7% interrupt, 25.0% idle Mem: 417M Active, 25M Inact, 118M Wired, 960K Cache, 83M Buf, 2699M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 13 root 1 171 52 0K 8K CPU1 0 0:00 99.02% idle: cpu1 112 root 1 -44 -163 0K 8K CPU3 3 5:25 63.77% swi1: net 62 root 1 -68 -187 0K 8K CPU3 3 3:40 45.12% irq64: em0 30 root 1 -64 -183 0K 8K CPU0 3 0:52 6.15% irq16: uhci0 110 root 1 -32 -151 0K 8K RUN 0 0:46 1.81% swi4: clock sio 2253 root 1 -8 0 4060K 2088K piperd 2 0:02 0.59% rotatelogs 2257 www 69 20 0 44476K 31292K kserel 2 0:15 0.05% httpd 12 root 1 171 52 0K 8K RUN 2 568:59 0.00% idle: cpu2 11 root 1 171 52 0K 8K RUN 3 566:19 0.00% idle: cpu3 14 root 1 171 52 0K 8K RUN 0 564:44 0.00% idle: cpu0 Server-A load snap shot. last pid: 1789; load averages: 0.90, 0.52, 0.25 up 0+09:36:30 23:58:06 132 processes: 7 running, 48 sleeping, 76 waiting, 1 lock CPU states: 5.2% user, 0.0% nice, 58.8% system, 36.0% interrupt, 0.0% idle Mem: 18M Active, 6924K Inact, 24M Wired, 4K Cache, 9472K Buf, 1908M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 1789 root 1 118 0 25980K 10312K RUN 1:28 62.95% ab 83 root 1 -44 -163 0K 16K RUN 2:44 16.46% swi1: net 59 root 1 -68 -187 0K 16K RUN 1:45 13.13% irq64: em2 27 root 1 -68 -187 0K 16K *Giant 0:42 3.22% irq16: em0 uhci0 11 root 1 171 52 0K 16K RUN 565:16 0.00% idle 84 root 1 -32 -151 0K 16K RUN 0:25 0.00% swi4: clock sio A> netstat -i | egrep 'em2.*Link|Name' Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll em2 1500 00:14:22:15:ff:8e 48321027 0 53902829 0 0 C> netstat -i | egrep 'Name|em0.*Link' Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll em0 1500 00:14:22:12:4c:03 53903066 0 48320427 0 0 ################## Detailed netstat -s output, (Patched) This output was after the first patched ab test. C> netstat -s tcp: 25376005 packets sent 6513686 data packets (207546682 bytes) 709236 data packets (1023477672 bytes) retransmitted 528 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 14624527 ack-only packets (405291 delayed) 0 URG only packets 0 window probe packets 4233326 window update packets 1722 control packets 35938560 packets received 4028982 acks (for 207454007 bytes) 1240 duplicate acks 0 acks for unsent data 30734610 packets (943374026 bytes) received in-sequence 219 completely duplicate packets (27559 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 1182576 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 573 connection requests 1496 connection accepts 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 2066 connections established (including accepts) 2078 connections closed (including 873 drops) 892 connections updated cached RTT on close 919 connections updated cached RTT variance on close 913 connections updated cached ssthresh on close 3 embryonic connections dropped 4028982 segments updated rtt (of 3716704 attempts) 82407 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 332121 correct ACK header predictions 30711908 correct data packet header predictions 1496 syncache entries added 0 retransmitted 0 dupsyn 1 dropped 1496 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 0 cookies sent 0 cookies received 10 SACK recovery episodes 0 segment rexmits in SACK recovery episodes 0 byte rexmits in SACK recovery episodes 84 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow udp: 28 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 0 dropped due to no socket 0 broadcast/multicast datagrams dropped due to no socket 0 dropped due to full socket buffers 0 not for hashed pcb 28 delivered 30 datagrams output ip: 35938589 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 35938588 packets for this host 0 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 1 packet not forwardable 0 packets received for unknown multicast group 0 redirects sent 26082806 packets sent from this host 0 packets sent with fabricated ip header 706706 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header (non patched) netstat -s output Server-C after ab benchmarking C>netstat -s tcp: 80819322 packets sent 38131626 data packets (2094911993 bytes) 3391261 data packets (596376915 bytes) retransmitted 2466 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 32726002 ack-only packets (471792 delayed) 0 URG only packets 0 window probe packets 9363807 window update packets 577867 control packets 99932094 packets received 22930997 acks (for 2088935510 bytes) 166038 duplicate acks 0 acks for unsent data 68050890 packets (2507301359 bytes) received in-sequence 10977 completely duplicate packets (83343 bytes) 3 old duplicate packets 4 packets with some dup. data (393 bytes duped) 178 out-of-order packets (185678 bytes) 13973 packets (1584 bytes) of data after window 0 window probes 8540928 window update packets 10 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 239473 connection requests 233007 connection accepts 96 bad connection attempts 356 listen queue overflows 0 ignored RSTs in the windows 345945 connections established (including accepts) 472549 connections closed (including 6743 drops) 7009 connections updated cached RTT on close 7052 connections updated cached RTT variance on close 6223 connections updated cached ssthresh on close 126535 embryonic connections dropped 22879742 segments updated rtt (of 19373996 attempts) 617076 retransmit timeouts 1 connection dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 2076 keepalive timeouts 8 keepalive probes sent 2068 connections dropped by keepalive 258255 correct ACK header predictions 67282248 correct data packet header predictions 233228 syncache entries added 438 retransmitted 2 dupsyn 224 dropped 233007 completed 220 bucket overflow 0 cache overflow 7 reset 1 stale 356 aborted 0 badack 0 unreach 0 zone failures 0 cookies sent 363 cookies received 385 SACK recovery episodes 305 segment rexmits in SACK recovery episodes 432188 byte rexmits in SACK recovery episodes 3004 SACK options (SACK blocks) received 245 SACK options (SACK blocks) sent 0 SACK scoreboard overflow udp: 78 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 3 dropped due to no socket 0 broadcast/multicast datagrams dropped due to no socket 0 dropped due to full socket buffers 0 not for hashed pcb 75 delivered 112 datagrams output ip: 99583810 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 99583796 packets for this host 0 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 4 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 83968104 packets sent from this host 0 packets sent with fabricated ip header 3372686 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header Gleb Smirnoff wrote: > Michael, > > big thanks for a very detailed report! > > On your next test round, can you please also keep an eye on >the CPU load. Is it increased measurably by the patch or not. > > Thanks again! > > > From owner-freebsd-net@FreeBSD.ORG Sun Oct 23 07:32:32 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 1F12916A41F for ; Sun, 23 Oct 2005 07:32:32 +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 7144B43D45 for ; Sun, 23 Oct 2005 07:32:31 +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 j9N7WTEI039828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Oct 2005 11:32:30 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j9N7WT5h039827; Sun, 23 Oct 2005 11:32:29 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 23 Oct 2005 11:32:29 +0400 From: Gleb Smirnoff To: Michael VInce Message-ID: <20051023073229.GT59364@cell.sick.ru> References: <20051020140200.GL59364@cell.sick.ru> <4359FFE3.7060001@roq.com> <20051022091905.GH59364@cell.sick.ru> <435B3A92.1040600@roq.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <435B3A92.1040600@roq.com> User-Agent: Mutt/1.5.6i Cc: net@FreeBSD.org Subject: Re: em(4) patch for test 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: Sun, 23 Oct 2005 07:32:32 -0000 On Sun, Oct 23, 2005 at 05:24:02PM +1000, Michael VInce wrote: M> Here is my second round of my non scientific benchmarking and tests, I M> hope this is useful. M> I been having fun benchmarking these machines but I am starting to get M> sick of it as well :) but I find it important to know that things are M> going to work right when they are launched to do their real work. M> M> The final results look good after patching and running ab tests I was M> unable to get errors out of netstat -i output, even when grilling the M> server-C machine to a rather high load. Again big thanks! I must note that increased speed in your test isn't a luck. If we get rid of errors, that are lost packets, surely TCP speed will increase. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Sun Oct 23 08:30: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 7941416A434 for ; Sun, 23 Oct 2005 08:30:19 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: from web35705.mail.mud.yahoo.com (web35705.mail.mud.yahoo.com [66.163.179.159]) by mx1.FreeBSD.org (Postfix) with SMTP id B9F0C43D4C for ; Sun, 23 Oct 2005 08:30:15 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: (qmail 18294 invoked by uid 60001); 23 Oct 2005 08:30:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4Wt2Ab9cl0h8qPd52bZgNT4OHUuj54ivLC2kH2KLHLN7HDTfvDZ2Of1zSN/6LTQFrpV1GXQdXEN45P8Uvm2yK8aaF35HMHYPydEoT2qpErVIzK37wxh76+cemzY4G00I+aiu/rtcN/1uBbl42Qu8ZZzwcVfKuwtvgL4DtUBuJGs= ; Message-ID: <20051023083015.18292.qmail@web35705.mail.mud.yahoo.com> Received: from [202.79.62.15] by web35705.mail.mud.yahoo.com via HTTP; Sun, 23 Oct 2005 01:30:15 PDT Date: Sun, 23 Oct 2005 01:30:15 -0700 (PDT) From: kamal kc To: freebsd MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd Subject: in_cksum() for ip packets with multiple mbufs 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: Sun, 23 Oct 2005 08:30:19 -0000 i come across this unusual problem. i changed the ip_tos field of the struct ip and computed the checksum by using in_cksum(). when the packet uses only one mbuf the computed checksum is ok but when the packet uses more than one mbuf then the computed checksum is wrong. eg. pinging with payload less than 1470 bytes is ok but with payload greater than 1480 bytes does not work. (the error being bad checksum --that i knew by capturing network packets by ethereal) is it a real problem or i have made some mistake. i put the code before the if_output() in the ip_output() function. help !! kamal __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From owner-freebsd-net@FreeBSD.ORG Sun Oct 23 10:20: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 82D8616A41F; Sun, 23 Oct 2005 10:20:57 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCB0743D45; Sun, 23 Oct 2005 10:20:56 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from flame.pc (aris.bedc.ondsl.gr [62.103.39.226]) by aiolos.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id j9NAKs0T006593; Sun, 23 Oct 2005 13:20:55 +0300 Received: from flame.pc (flame [127.0.0.1]) by flame.pc (8.13.4/8.13.4) with ESMTP id j9NAJKew020145; Sun, 23 Oct 2005 13:19:20 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by flame.pc (8.13.4/8.13.4/Submit) id j9NAJKCB020118; Sun, 23 Oct 2005 13:19:20 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Sun, 23 Oct 2005 13:19:20 +0300 From: Giorgos Keramidas To: kamal kc Message-ID: <20051023101919.GA9957@flame.pc> References: <20051023083015.18292.qmail@web35705.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051023083015.18292.qmail@web35705.mail.mud.yahoo.com> Cc: freebsd , freebsd Subject: Re: in_cksum() for ip packets with multiple mbufs 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: Sun, 23 Oct 2005 10:20:57 -0000 On 2005-10-23 01:30, kamal kc wrote: > i come across this unusual problem. > > i changed the ip_tos field of the struct ip and computed the checksum > by using in_cksum(). > > when the packet uses only one mbuf the computed checksum is ok but > when the packet uses more than one mbuf then the computed checksum is > wrong. Note that the IP header contains a checksum of the IP header only. A common mistake is to calculate the checksum of data too, which results in an invalid IP header checksum. > eg. pinging with payload less than 1470 bytes is ok but with payload > greater than 1480 bytes does not work. (the error being bad checksum > --that i knew by capturing network packets by ethereal) > > is it a real problem or i have made some mistake. > > i put the code before the if_output() in the ip_output() function. Show us the diff, if possible :) From owner-freebsd-net@FreeBSD.ORG Sun Oct 23 10:51: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 8EAB316A421 for ; Sun, 23 Oct 2005 10:51:57 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from corwin.easynet.fr (smarthost168.mail.easynet.fr [212.180.1.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2780543D46 for ; Sun, 23 Oct 2005 10:51:56 +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 1ETdSE-0007KA-So for freebsd-net@freebsd.org; Sun, 23 Oct 2005 12:51:55 +0200 Received: from localhost.localdomain (spartacus.zen.inc [192.168.1.20]) by smtp.zeninc.net (smtpd) with ESMTP id 8AB803F17 for ; Sun, 23 Oct 2005 12:51:49 +0200 (CEST) Received: by localhost.localdomain (Postfix, from userid 1000) id 5D39185609; Sun, 23 Oct 2005 12:51:49 +0200 (CEST) Date: Sun, 23 Oct 2005 12:51:49 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20051023105149.GA2532@zeninc.net> References: <435A85F7.3000909@shrew.net> <435AA8BA.6020808@vwsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <435AA8BA.6020808@vwsoft.com> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: IPSec tcp session stalling ( me too ) ... 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: Sun, 23 Oct 2005 10:51:57 -0000 On Sat, Oct 22, 2005 at 10:01:46PM +0100, Volker wrote: [....] > Is anybody else here with deep TCP + IPSec knowledge able to get a look > into this? Any known issues? Is there anything I might also check out? > Is there a 64k limit with IPSec? :( IPSec works, even for huge datas sessions: I'm using it every day, and a lot of my customers would already have complained about it if there were such problems ! :-) As I said before, this really looks like problems I regulary see, when the ESP packets will have to be fragmented (ESP adds an encapsulation level). Use a lower MTU on your traffic endpoints or play with the TCPMSS value on one gate (at least pf can be configured to do that), and ensure that there is no more fragmented ESP packets between the IPSec gates (of course, TCPMSS solution is easier to set up, but will only work for TCP sessions...). ESP maximum overhead is 4 (SPI) + 4 (seq number) + 255 (padding) + 2 (pad len + next header) + 96 (SHA-1-96 auth value, see RFC 2404) bytes, but usually, overhead will be around 100 bytes (including authentication, but ESP should really not be used without authentication), so setting up for internal hosts an MTU of (Public Interface MTU) - 150 should be enough, without really decreasing global performances. You should also have better performances when this will be fixed. Yvan. -- NETASQ - Secure Internet Connectivity http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Sun Oct 23 11:13: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 90EC316A41F for ; Sun, 23 Oct 2005 11:13:34 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: from web35701.mail.mud.yahoo.com (web35701.mail.mud.yahoo.com [66.163.179.155]) by mx1.FreeBSD.org (Postfix) with SMTP id B279043D48 for ; Sun, 23 Oct 2005 11:13:33 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: (qmail 53652 invoked by uid 60001); 23 Oct 2005 11:13:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=cavUSpZcLCp8U/AE3PuwW3MRUTseWCcLMnpUtPw0VFKE6OK51hLs/+wHN1Hmb1W3uV65VHAmntmvs76nFuKoHrISw3uw55EGJT13ZlkwENUQk8sEaH+PD5JeQfPiDXM9fZq6KFzBub3HDoWWsvhxPzAqVHpE6qV/eeVyt+VKv/c= ; Message-ID: <20051023111333.53650.qmail@web35701.mail.mud.yahoo.com> Received: from [202.79.62.15] by web35701.mail.mud.yahoo.com via HTTP; Sun, 23 Oct 2005 04:13:33 PDT Date: Sun, 23 Oct 2005 04:13:33 -0700 (PDT) From: kamal kc To: Giorgos Keramidas In-Reply-To: <20051023101919.GA9957@flame.pc> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd , freebsd Subject: Re: in_cksum() for ip packets with multiple mbufs 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: Sun, 23 Oct 2005 11:13:34 -0000 > > i changed the ip_tos field of the struct ip and > computed the checksum > > by using in_cksum(). > > > > when the packet uses only one mbuf the computed > checksum is ok but > > when the packet uses more than one mbuf then the > computed checksum is > > wrong. > > Note that the IP header contains a checksum of the > IP header only. > > A common mistake is to calculate the checksum of > data too, which results > in an invalid IP header checksum. ok i made this mistake to calculate the checksum over the entire IP payload. i corrected this and used the ip_hl field ::: /* the argument m is the (struct mbuf *) that * contains the packet data */ void copy_the_memorybuffer(struct mbuf **m) { struct mbuf *mbuf_pointer=*m; struct mbuf **next_packet; next_packet=&mbuf_pointer; struct ip *my_ip_hdr; my_ip_hdr=mtod((*next_packet),struct ip *); my_ip_hdr->ip_tos=64; my_ip_hdr->ip_sum=0; my_ip_hdr->ip_sum= in_cksum((*next_packet),(my_ip_hdr->ip_hl<<2)); ....... } but still it doesn't seem to work. and the problem is still there. i am really confused .. > > eg. pinging with payload less than 1470 bytes is > ok but with payload > > greater than 1480 bytes does not work. (the error > being bad checksum > > --that i knew by capturing network packets by > ethereal) > > > > is it a real problem or i have made some mistake. > > > > i put the code before the if_output() in the > ip_output() function. > > Show us the diff, if possible :) sorry i did not understand what to show here. does it mean to show the packet data captured by the ethereal.. thanks kamal __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com From owner-freebsd-net@FreeBSD.ORG Sun Oct 23 12:06:20 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 787A316A41F; Sun, 23 Oct 2005 12:06:20 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8000B43D46; Sun, 23 Oct 2005 12:06:18 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from flame.pc (aris.bedc.ondsl.gr [62.103.39.226]) by rosebud.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id j9NC6G3M008871; Sun, 23 Oct 2005 15:06:17 +0300 Received: from flame.pc (flame [127.0.0.1]) by flame.pc (8.13.4/8.13.4) with ESMTP id j9NC4gEG030056; Sun, 23 Oct 2005 15:04:42 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by flame.pc (8.13.4/8.13.4/Submit) id j9NC4gmu030055; Sun, 23 Oct 2005 15:04:42 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Sun, 23 Oct 2005 15:04:42 +0300 From: Giorgos Keramidas To: kamal kc Message-ID: <20051023120442.GB29924@flame.pc> References: <20051023101919.GA9957@flame.pc> <20051023111333.53650.qmail@web35701.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051023111333.53650.qmail@web35701.mail.mud.yahoo.com> Cc: freebsd , freebsd Subject: Re: in_cksum() for ip packets with multiple mbufs 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: Sun, 23 Oct 2005 12:06:20 -0000 On 2005-10-23 04:13, kamal kc wrote: > /* the argument m is the (struct mbuf *) that > * contains the packet data > */ > > void copy_the_memorybuffer(struct mbuf **m) > { > struct mbuf *mbuf_pointer=*m; > struct mbuf **next_packet; > > next_packet=&mbuf_pointer; > > struct ip *my_ip_hdr; > my_ip_hdr=mtod((*next_packet),struct ip *); > my_ip_hdr->ip_tos=64; > my_ip_hdr->ip_sum=0; > > my_ip_hdr->ip_sum= > in_cksum((*next_packet),(my_ip_hdr->ip_hl<<2)); > ....... > } Why all this pointer fun? How do you know that it's safe to dereference `m' when you do: struct mbuf *mbuf_pointer=*m; Why are you dereferencing `m' once to obtain mbuf_pointer and then taking the address of that to obtain next_packet, when you could just do: next_packet = m; There are also several other problems with copy_the_memorybuffer() as it's written above: - It's considered bad style to mix declarations and code the way you have done above - It is probably better to return the copy of the mbuf you're fiddling with, instead of modifying in place a parameter of the function. - If you are not *REALLY* copying the data of the mbuf, then the name of copy_the_memorybuffer() is very confusing. - What is the magic constant 64 that is assigned to ip_tos? What you probably want to do is something like: void ip_set_type_of_service(struct mbuf *m) { struct ip *iph; assert(m != NULL); iph = mtod(m, struct ip *); iph->ip_tos = IPTOS_PREC_IMMEDIATE; iph->ip_sum = 0; iph->ip_sum = in_cksum((uint16_t *)iph, iph->ip_hl << 2); } but that's not copying anything. > but still it doesn't seem to work. and the problem > is still there. You have obviously made a lot of changes that we haven't seen yet. Instead of posting snippets here and there, save a copy of the original sources somewhere, then a copy of the new sources, and run diff(1) on the two directories to extract *ALL* the changes. $ cd /usr/src $ diff -ruN src.old/ src/ > /tmp/patchfile and put the patchfile somewhere online where we can have a look at all the changes. From owner-freebsd-net@FreeBSD.ORG Sun Oct 23 13:16: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 76BC316A41F for ; Sun, 23 Oct 2005 13:16:22 +0000 (GMT) (envelope-from volker@vwsoft.com) Received: from tce71.tce85.de (tce71.tce85.de [195.145.102.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDD6043D46 for ; Sun, 23 Oct 2005 13:16:21 +0000 (GMT) (envelope-from volker@vwsoft.com) Received-SPF: pass (tce71.tce85.de: domain of vwsoft.com designates 84.245.169.89 as permitted sender) client-ip=84.245.169.89; envelope-from=volker@vwsoft.com; helo=mail.vtec.ipme.de; Received: from mail.vtec.ipme.de (84-245-169-89.ipool.celox.de [84.245.169.89]) by tce71.tce85.de (Postfix) with ESMTP id C7AFE17120 for ; Sun, 23 Oct 2005 15:16:25 +0200 (CEST) Received: from [192.168.16.3] (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id 9E13B5C4E; Sun, 23 Oct 2005 14:57:01 +0200 (CEST) Message-ID: <435B96B0.1080409@vwsoft.com> Date: Sun, 23 Oct 2005 14:57:04 +0100 From: Volker User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Thunderbird/1.0.6 Mnenhy/0.6.0.101 X-Accept-Language: en-us, en MIME-Version: 1.0 To: VANHULLEBUS Yvan References: <20051023120048.20AB916A423@hub.freebsd.org> In-Reply-To: <20051023120048.20AB916A423@hub.freebsd.org> X-Enigmail-Version: 0.92.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-TarmacCE-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com Cc: freebsd-net@freebsd.org Subject: Re: IPSec tcp session stalling ( me too ) ... 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: Sun, 23 Oct 2005 13:16:22 -0000 Yvan, as far as I'm not totally wrong on the MTU issue, I've already checked that. On the other side, if it's an MTU issue, wouldn't the stream break at the first oversized packet? I mean the scp session is sending around 56k of data through the stream and then the session stalls. My gnetcat test setup was able to get somewhat around 64k of data through the tunnel before the session gets aborted. >From my view if it's an MTU issue it has to stall when the first 2, 3 or 4 kByte have been transmitted. Am I wrong? Also I already tried to play around with pf and set max-mss as low as 640 or 576 just for testing this. It didn't solve anything. As written in my first post of this thread, the gifX interface already has the lowest possible MTU (by default) of 1280. The underlaying interface (emX on hostA, ng0 on hostB) has an MTU of 1500 (emX) and 1492 (ng0). That should already give enough room (>200byte) for IPSec headers (as long as the whole path between both hosts does support an MTU of 1500). I'm currently in the process of switching to FAST_IPSEC on both machines and will repeat the test. It takes a bit longer as both machines are remote to me. Thanks for your help! Volker Yvan wrote: > > As I said before, this really looks like problems I regulary see, when > the ESP packets will have to be fragmented (ESP adds an encapsulation > level). > > Use a lower MTU on your traffic endpoints or play with the TCPMSS > value on one gate (at least pf can be configured to do that), and > ensure that there is no more fragmented ESP packets between the IPSec > gates (of course, TCPMSS solution is easier to set up, but will only > work for TCP sessions...). > > ESP maximum overhead is 4 (SPI) + 4 (seq number) + 255 (padding) + 2 > (pad len + next header) + 96 (SHA-1-96 auth value, see RFC 2404) > bytes, but usually, overhead will be around 100 bytes (including > authentication, but ESP should really not be used without > authentication), so setting up for internal hosts an MTU of (Public > Interface MTU) - 150 should be enough, without really decreasing > global performances. > > > You should also have better performances when this will be fixed. > > > > Yvan. > > -- NETASQ - Secure Internet Connectivity http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Sun Oct 23 19:34: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 70BAB16A41F; Sun, 23 Oct 2005 19:34:26 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5BE243D45; Sun, 23 Oct 2005 19:34:25 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by freebsd.czest.pl (8.12.10/8.12.9) with ESMTP id j9NJYQaq083479; Sun, 23 Oct 2005 19:34:26 GMT (envelope-from dunstan@freebsd.czest.pl) Received: (from dunstan@localhost) by freebsd.czest.pl (8.12.10/8.12.9/Submit) id j9NJYQpL083478; Sun, 23 Oct 2005 19:34:26 GMT (envelope-from dunstan) Date: Sun, 23 Oct 2005 19:34:25 +0000 From: "Wojciech A. Koszek" To: Andrew Thompson Message-ID: <20051023193425.GB83431@freebsd.czest.pl> References: <20051020202034.GA4556@freebsd.czest.pl> <20051020202327.GA53753@heff.fud.org.nz> <20051022133735.GA26636@freebsd.czest.pl> <20051022194506.GC62360@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051022194506.GC62360@heff.fud.org.nz> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: Dependency between interfaces 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: Sun, 23 Oct 2005 19:34:26 -0000 On Sun, Oct 23, 2005 at 08:45:06AM +1300, Andrew Thompson wrote: > On Sat, Oct 22, 2005 at 01:37:35PM +0000, Wojciech A. Koszek wrote: > > On Fri, Oct 21, 2005 at 09:23:27AM +1300, Andrew Thompson wrote: > > > On Thu, Oct 20, 2005 at 08:20:34PM +0000, Wojciech A. Koszek wrote: > > > > Hello, > > > > > > > > [..] > > > > > > Is it still a problem or did you test on a pre r1.26 kernel? > > > > > > > Results from -CURRENT: I got panic if sk/rl modules are loaded, interfaces > > added to bridge0 and these drivers kldunload(8)ed: > > > > http://freebsd.czest.pl/dunstan/FreeBSD/bridge_rl.trace > > http://freebsd.czest.pl/dunstan/FreeBSD/bridge_sk.trace > > > > Can you please try this patch. Problem seems to be fixed with this patch. BTW, thanks for pjd@ for his help in tracking my weird panic. -- * Wojciech A. Koszek && dunstan@FreeBSD.czest.pl From owner-freebsd-net@FreeBSD.ORG Mon Oct 24 02:49:02 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 D0F8D16A420; Mon, 24 Oct 2005 02:49:02 +0000 (GMT) (envelope-from fooler@skyinet.net) Received: from smtp1.skyinet.net (smtp1.skyinet.net [202.78.97.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A71943D49; Mon, 24 Oct 2005 02:49:00 +0000 (GMT) (envelope-from fooler@skyinet.net) Received: from fooler (fooler.ilo.skyinet.net [202.78.118.66]) by smtp1.skyinet.net (Postfix) with SMTP id 9E23D582CA; Mon, 24 Oct 2005 10:48:58 +0800 (PHT) Message-ID: <016201c5d845$84992820$42764eca@ilo.skyinet.net> From: To: "Marcin Jessa" References: <20051019235111.2225345e.lists@yazzy.org><20051020070145.GA59364@cell.sick.ru><20051020131549.5e432073.lists@yazzy.org><20051020123159.33f6fa33.lists@yazzy.org><07c501c5d5e1$0ddf67f0$42764eca@ilo.skyinet.net><20051021112934.7c857fcc.lists@yazzy.org><002801c5d634$fdc66bd0$42764eca@ilo.skyinet.net> <20051021145523.097758f5.lists@yazzy.org> Date: Mon, 24 Oct 2005 10:49:13 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Cc: glebius@FreeBSD.org, current@FreeBSD.org, net@FreeBSD.org Subject: Re: PPPoE and Radius on 6.0RC1 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, 24 Oct 2005 02:49:03 -0000 ----- Original Message ----- From: "Marcin Jessa" To: Cc: ; ; Sent: Friday, October 21, 2005 8:55 PM Subject: Re: PPPoE and Radius on 6.0RC1 > Thanks a lot. > I recompiled my kernel with the netgraph options and set up the > server with your configs. Besides from the fact that I only use my fxp0 > in the tests. > root 787 0.0 0.1 1256 796 ?? Ss 2:41PM > 0:00.02 /usr/libexec/pppoed -l PPPoE -P /var/run/pppoed.pid -p * fxp0 ok... but i would like to suggest your pppoe clients must be facing the ip less interface nic so that clients would not put static configuration on their side to defeat your pppoe configuration :-> > I disabled radius as well adding username and password by > hand. without radius does it worked? > Although the radius itself works fine when I test it with radtest > and user's credits. > Just like before, nothing gets loged in ppp.log and the ppp process > itself never gets started up by the pppoe daemon. does your radius server supports microsoft chap version 2? my config given to you only authenticates mschapv2... > "on receipt of the SUCCESS indication, pppoed > will execute exec /usr/sbin/ppp -direct label" > - This part is not taking place.... actually pppoed did executed ppp.... ppp will exit immediately if it sees something wrong with its configuration, authentication and others... fooler. From owner-freebsd-net@FreeBSD.ORG Mon Oct 24 04:54:25 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 1D99C16A41F for ; Mon, 24 Oct 2005 04:54:25 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB65443D49 for ; Mon, 24 Oct 2005 04:54:24 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id BBA5A4C5EF; Mon, 24 Oct 2005 04:54:24 +0000 (GMT) Received: by p4.roq.com (Postfix, from userid 1007) id A0AC44CCF5; Mon, 24 Oct 2005 04:54:24 +0000 (GMT) Received: from [192.168.0.3] (ppp157-158.static.internode.on.net [150.101.157.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by p4.roq.com (Postfix) with ESMTP id 0412E4C5EF; Mon, 24 Oct 2005 04:54:21 +0000 (GMT) Message-ID: <435C68FC.9090506@roq.com> Date: Mon, 24 Oct 2005 14:54:20 +1000 From: Michael VInce User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20051019 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael VInce , net@FreeBSD.org References: <20051020140200.GL59364@cell.sick.ru> <4359FFE3.7060001@roq.com> <20051022091905.GH59364@cell.sick.ru> <435B3A92.1040600@roq.com> In-Reply-To: <435B3A92.1040600@roq.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on p4.roq.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.4 X-Virus-Scanned: ClamAV using ClamSMTP Cc: Subject: Re: em(4) patch for test 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, 24 Oct 2005 04:54:25 -0000 I just have to point out that below I made a statement that proved I should of gone to bed earlier instead of doing benchmarks :). The 901 http States and ssh state have nothing to do with each other as there on different pf rules. Mike Michael VInce wrote: > I did watch the gateway (B) pf state table and did an ab test with and > without pf running, I didn't see any difference in results when having > pf running with stateful rules, ab's Time per requests stayed low and > transfer rates stayed high. Most of the time the total states were > exactly 900 (plus 1 for ssh session) which would make sense > considering the 900 keep-alive concurrency level on the ab test. > > pftop output > RULE ACTION DIR LOG Q IF PR K PKTS BYTES STATES MAX > INFO > 0 Pass In Q em2 tcp M 37362067 1856847K 901 > inet from any to server-c port = http > > From owner-freebsd-net@FreeBSD.ORG Mon Oct 24 05:27: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 41A4E16A41F for ; Mon, 24 Oct 2005 05:27:02 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: from web35705.mail.mud.yahoo.com (web35705.mail.mud.yahoo.com [66.163.179.159]) by mx1.FreeBSD.org (Postfix) with SMTP id 9BCEE43D46 for ; Mon, 24 Oct 2005 05:27:01 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: (qmail 63217 invoked by uid 60001); 24 Oct 2005 05:27:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=N79z5gnjr6mNXJoLZb81I5twdTYK5SGYObEvqRSJsvupfSO5HIm3hphLWqrC57eUUU+8tJq0wpPhu23wL1g//2v7MbYiSiPTFfu9lJ46SYFKEO2S4LbWvF1RFZv/r5rrgNqxH5/Z0RT73Y8EMn8b3wuQDVLnoYn6//Wp5cc++G8= ; Message-ID: <20051024052700.63215.qmail@web35705.mail.mud.yahoo.com> Received: from [202.79.62.15] by web35705.mail.mud.yahoo.com via HTTP; Sun, 23 Oct 2005 22:27:00 PDT Date: Sun, 23 Oct 2005 22:27:00 -0700 (PDT) From: kamal kc To: Giorgos Keramidas In-Reply-To: <20051023120442.GB29924@flame.pc> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd , freebsd Subject: Re: in_cksum() for ip packets with multiple mbufs 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, 24 Oct 2005 05:27:02 -0000 > > void copy_the_memorybuffer(struct mbuf **m) > > { > > struct mbuf *mbuf_pointer=*m; > > struct mbuf **next_packet; > > > > next_packet=&mbuf_pointer; > > > > struct ip *my_ip_hdr; > > my_ip_hdr=mtod((*next_packet),struct ip *); > > my_ip_hdr->ip_tos=64; > > my_ip_hdr->ip_sum=0; > > > > my_ip_hdr->ip_sum= > > > in_cksum((*next_packet),(my_ip_hdr->ip_hl<<2)); > > ....... > > } > > Why all this pointer fun? How do you know that it's > safe to dereference > `m' when you do: > > struct mbuf *mbuf_pointer=*m; > > Why are you dereferencing `m' once to obtain > mbuf_pointer and then > taking the address of that to obtain next_packet, > when you could > just do: > > next_packet = m; > > There are also several other problems with > copy_the_memorybuffer() as > it's written above: > > - It's considered bad style to mix declarations > and code the way you > have done above > > - It is probably better to return the copy of > the mbuf you're > fiddling with, instead of modifying in place a > parameter of the > function. one thing i would like to ask? does it make any difference if i free the mbuf 'm' passed to if_output() and pass my own mbuf to if_output. is the original mbuf referenced by any other pointers or global variables ?? i couldn't figure out much from the sources. > - If you are not *REALLY* copying the data of > the mbuf, then > the name of copy_the_memorybuffer() is very > confusing. i didn't showed in the above code snippet but actually i am copying the data contained in the mbufs in a character array. my purpose is to compress the data contained in the ip packet > - What is the magic constant 64 that is assigned > to ip_tos? that was just to see that i could actually modify the ip header. > What you probably want to do is something like: > > void > ip_set_type_of_service(struct mbuf *m) > { > struct ip *iph; > > assert(m != NULL); > > iph = mtod(m, struct ip *); > iph->ip_tos = IPTOS_PREC_IMMEDIATE; > iph->ip_sum = 0; > iph->ip_sum = in_cksum((uint16_t *)iph, > iph->ip_hl << 2); > } thanks i will try this code and try to make the code simpler next time. > but that's not copying anything. > > > but still it doesn't seem to work. and the problem > > is still there. > > You have obviously made a lot of changes that we > haven't seen yet. > Instead of posting snippets here and there, save a > copy of the original > sources somewhere, then a copy of the new sources, > and run diff(1) on > the two directories to extract *ALL* the changes. > > $ cd /usr/src > $ diff -ruN src.old/ src/ > /tmp/patchfile > > and put the patchfile somewhere online where we can > have a look at all > the changes. i am new to kernel sources and kernel programming and thank you for informing me on the diff(1). thanks to you that the problem was solved (i don't know if it is completely ok). i found that - i had made mistake in computing checksum. earlier checksum was computed over the whole dat I may soon put up patchfiles on web. thanks. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-net@FreeBSD.ORG Mon Oct 24 05:35:33 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 687B816A435 for ; Mon, 24 Oct 2005 05:35:33 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: from web35709.mail.mud.yahoo.com (web35709.mail.mud.yahoo.com [66.163.179.163]) by mx1.FreeBSD.org (Postfix) with SMTP id C100B43D45 for ; Mon, 24 Oct 2005 05:35:32 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: (qmail 48334 invoked by uid 60001); 24 Oct 2005 05:35:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LwyplNWoknRYIRyr3cEF93UzrDitRl+69AiAaSSDvtRo1KwNwHi6ShUICFtIb5jS6qTP1wybn49SVDefsVzXjCx3bhinvFeG4Uva5+iJZ1nJjCHmTKL35q62lhKRGl/VgSTncnBNX3ZfF9reV5fU7pDrt+ST+HNbiXncTKcWRFA= ; Message-ID: <20051024053532.48332.qmail@web35709.mail.mud.yahoo.com> Received: from [202.79.62.15] by web35709.mail.mud.yahoo.com via HTTP; Sun, 23 Oct 2005 22:35:32 PDT Date: Sun, 23 Oct 2005 22:35:32 -0700 (PDT) From: kamal kc To: Giorgos Keramidas In-Reply-To: <20051023120442.GB29924@flame.pc> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd , freebsd Subject: Re: in_cksum() for ip packets with multiple mbufs 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, 24 Oct 2005 05:35:33 -0000 > > void copy_the_memorybuffer(struct mbuf **m) > > { > > struct mbuf *mbuf_pointer=*m; > > struct mbuf **next_packet; > > > > next_packet=&mbuf_pointer; > > > > struct ip *my_ip_hdr; > > my_ip_hdr=mtod((*next_packet),struct ip *); > > my_ip_hdr->ip_tos=64; > > my_ip_hdr->ip_sum=0; > > > > my_ip_hdr->ip_sum= > > > in_cksum((*next_packet),(my_ip_hdr->ip_hl<<2)); > > ....... > > } > > Why all this pointer fun? How do you know that it's > safe to dereference > `m' when you do: > > struct mbuf *mbuf_pointer=*m; > > Why are you dereferencing `m' once to obtain > mbuf_pointer and then > taking the address of that to obtain next_packet, > when you could > just do: > > next_packet = m; > > There are also several other problems with > copy_the_memorybuffer() as > it's written above: > > - It's considered bad style to mix declarations > and code the way you > have done above > > - It is probably better to return the copy of > the mbuf you're > fiddling with, instead of modifying in place a > parameter of the > function. one thing i would like to ask? does it make any difference if i free the mbuf 'm' passed to if_output() and pass my own mbuf to if_output. is the original mbuf referenced by any other pointers or global variables ?? i couldn't figure out much from the sources. > - If you are not *REALLY* copying the data of > the mbuf, then > the name of copy_the_memorybuffer() is very > confusing. i didn't showed in the above code snippet but actually i am copying the data contained in the mbufs in a character array. my purpose is to compress the data contained in the ip packet > - What is the magic constant 64 that is assigned > to ip_tos? that was just to see that i could actually modify the ip header. > What you probably want to do is something like: > > void > ip_set_type_of_service(struct mbuf *m) > { > struct ip *iph; > > assert(m != NULL); > > iph = mtod(m, struct ip *); > iph->ip_tos = IPTOS_PREC_IMMEDIATE; > iph->ip_sum = 0; > iph->ip_sum = in_cksum((uint16_t *)iph, > iph->ip_hl << 2); > } thanks i will try this code and try to make the code simpler next time. > but that's not copying anything. > > > but still it doesn't seem to work. and the problem > > is still there. > > You have obviously made a lot of changes that we > haven't seen yet. i did not put the whole code because i am a bit lazy and the code is cumbersome. and i thought that it was causing the problem. > Instead of posting snippets here and there, save a > copy of the original > sources somewhere, then a copy of the new sources, > and run diff(1) on > the two directories to extract *ALL* the changes. > > $ cd /usr/src > $ diff -ruN src.old/ src/ > /tmp/patchfile > > and put the patchfile somewhere online where we can > have a look at all > the changes. i am new to kernel sources and kernel programming and thank you for informing me on the diff(1). thanks to you that the problem was solved (i don't know if it is completely ok). i found that - i had made mistake in computing checksum. earlier checksum was computed over the whole data but now i calculate checksum over the header only. - byte ordering. tell me one thing isn't the byte order of the ip_id in network byte order in the mbuf when passed to the if_output() ?? i had to use the htons() to ip_id before computing the checksum - final thing does this makes any difference (calling the htons() twice): ip->ip_id=htons(ip->ip_id); ip->ip_id=htons(ip->ip_id); I will try put up patchfiles on web. thanks very much, kamal __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From owner-freebsd-net@FreeBSD.ORG Mon Oct 24 07:31:20 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 E7E3716A41F; Mon, 24 Oct 2005 07:31:20 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CB8043D45; Mon, 24 Oct 2005 07:31:19 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from flame.pc (aris.bedc.ondsl.gr [62.103.39.226]) by rosebud.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id j9O7VHZg012074; Mon, 24 Oct 2005 10:31:18 +0300 Received: from flame.pc (flame [127.0.0.1]) by flame.pc (8.13.4/8.13.4) with ESMTP id j9O7TfaT001965; Mon, 24 Oct 2005 10:29:41 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by flame.pc (8.13.4/8.13.4/Submit) id j9O7TfTN001964; Mon, 24 Oct 2005 10:29:41 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Mon, 24 Oct 2005 10:29:41 +0300 From: Giorgos Keramidas To: kamal kc Message-ID: <20051024072941.GA1944@flame.pc> References: <20051023120442.GB29924@flame.pc> <20051024052700.63215.qmail@web35705.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051024052700.63215.qmail@web35705.mail.mud.yahoo.com> Cc: freebsd , freebsd Subject: Re: in_cksum() for ip packets with multiple mbufs 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, 24 Oct 2005 07:31:21 -0000 On 2005-10-23 22:27, kamal kc wrote: > one thing i would like to ask? > > does it make any difference if i free the mbuf 'm' passed to > if_output() and pass my own mbuf to if_output. > > is the original mbuf referenced by any other pointers or global > variables ?? If you are hooking your own functions right before if_output, then it shouldn't be a problem. > > - If you are not *REALLY* copying the data of the mbuf, then the > > name of copy_the_memorybuffer() is very confusing. > > i didn't showed in the above code snippet but actually i am copying > the data contained in the mbufs in a character array. AH! That makes more sense then :) > thanks to you that the problem was solved (i don't > know if it is completely ok). i found that > - i had made mistake in computing checksum. > earlier checksum was computed over the whole dat Nice. Glad to know it's fixed now. From owner-freebsd-net@FreeBSD.ORG Mon Oct 24 08:39:37 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 9FDB416A41F for ; Mon, 24 Oct 2005 08:39:37 +0000 (GMT) (envelope-from silby@silby.com) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.FreeBSD.org (Postfix) with SMTP id 1B2A543D45 for ; Mon, 24 Oct 2005 08:39:36 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 40901 invoked from network); 24 Oct 2005 08:39:35 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 24 Oct 2005 08:39:35 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 24 Oct 2005 03:39:34 -0500 (CDT) From: Mike Silbersack To: Jan Mikael Melen In-Reply-To: <200510091827.03988.jan@melen.org> Message-ID: <20051024033756.V26073@odysseus.silby.com> References: <200509251353.j8PDr5XE005907@lurza.secnetix.de> <200509271107.37830.jan@melen.org> <200510091827.03988.jan@melen.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Kernel panic due atheros driver after finalsync (Was: VIA VT6103 support (VIA EPIA PD)) 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, 24 Oct 2005 08:39:37 -0000 On Sun, 9 Oct 2005, Jan Mikael Melen wrote: > Hi, > > I have the D-Link DWL-G520 which has the atheros 5212 chip. When rebooting the > FreeBSD 6.0-BETA5 after the final sync kernel panics. If the if_ath module has > not been loaded in to the memory all works fine. Does anyone have any good > idea how to get rid of this problem? Unloading the kernel module will cause > the whole system to halt totally, the system does not respond to anything > except power button and reset ;) >From what you pasted, the problem appears to be that ath0 and vr0 share an interrupt, ath0 is triggering a late interrupt, and vr0 can't handle it. I think someone might've fixed the problem in -current, you should check the cvs history for if_vr.c. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Mon Oct 24 09:18:33 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 EE75316A41F for ; Mon, 24 Oct 2005 09:18:33 +0000 (GMT) (envelope-from silby@silby.com) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 7AB3D43D45 for ; Mon, 24 Oct 2005 09:18:33 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 66770 invoked from network); 24 Oct 2005 09:18:31 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 24 Oct 2005 09:18:31 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 24 Oct 2005 04:18:27 -0500 (CDT) From: Mike Silbersack To: Nicolas KOWALSKI In-Reply-To: Message-ID: <20051024041109.E26073@odysseus.silby.com> References: <20051014160128.hev160v52ossokg0@wwws.cs.ait.ac.th> <20051014045824.V5343@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org Subject: Re: FreeBSD NFS server not responding to TCP SYN packets from Linux/SunOS clients 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, 24 Oct 2005 09:18:34 -0000 Sorry for the delay, you took me out of the To: listing, so the message just went into my lists box, which I didn't get to until today. On Fri, 14 Oct 2005, Nicolas KOWALSKI wrote: >> Assuming that port reuse is the problem, there is no quick fix for >> this, just resetting connections when a SYN comes in would be a >> really big security problem. > > Really? Are Linux and Solaris that insecure because of this behaviour? Not necessarily - there are a bunch of different ways to handle the situation better than we do at present. I don't know how Solaris/Linux do it right now, nor have I had time to implement an improvement for FreeBSD. Maybe in January I'll have time. >> Actually, there may be a quick fix for this specific machine. If you >> set net.inet.tcp.keepidle to 1 minute (60*whatever kern.hz is), >> that'll cause keepalive packets to be sent every minute to an idle >> connection, rather than every 2 hours. That would kill the stuck >> connections much quicker. > > Unfortunately, this does not work as expected. I just tested with my > workstation (Linux 2.6), with NFS filesystems mounted with TCP; when > the station rebooted abruptely, mounting the same NFS filesystems hung > more than 1 minute (15 minutes just now). During this hang, I saw on > the server, using netstat, the nfsd process related to my workstation > in ESTABLISHED state. > > Any other tip? > > Many Thanks in advance, > -- > Nicolas Ok, I have one other quick fix idea, but it's a bit crazy. ipfw is supposed to send keepalive packets when rules go idle and are about to expire. So, if you make a keep-state rule for incoming connections, then maybe ipfw would somehow close down the dead connection. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Mon Oct 24 09:50: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 72C0A16A41F; Mon, 24 Oct 2005 09:50:34 +0000 (GMT) (envelope-from corecode@fs.ei.tum.de) Received: from stella.fs.ei.tum.de (stella.fs.ei.tum.de [129.187.54.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1950843D55; Mon, 24 Oct 2005 09:50:32 +0000 (GMT) (envelope-from corecode@fs.ei.tum.de) Received: from localhost (localhost [127.0.0.1]) by localhost.fs.ei.tum.de (Postfix) with ESMTP id 33B8E8DC3F; Mon, 24 Oct 2005 11:50:31 +0200 (CEST) Received: from stella.fs.ei.tum.de ([127.0.0.1]) by localhost (stella [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31742-06; Mon, 24 Oct 2005 11:50:31 +0200 (CEST) Received: from [10.150.180.180] (r180180.olydorf.swh.mhn.de [10.150.180.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by stella.fs.ei.tum.de (Postfix) with ESMTP id C75CF8D759; Mon, 24 Oct 2005 11:50:30 +0200 (CEST) Message-ID: <435CAE85.2050509@fs.ei.tum.de> Date: Mon, 24 Oct 2005 11:51:01 +0200 From: Simon 'corecode' Schubert User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050912) X-Accept-Language: en-us, en MIME-Version: 1.0 To: kamal kc References: <20051024053532.48332.qmail@web35709.mail.mud.yahoo.com> In-Reply-To: <20051024053532.48332.qmail@web35709.mail.mud.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at fs.ei.tum.de Cc: Giorgos Keramidas , freebsd , freebsd Subject: Re: in_cksum() for ip packets with multiple mbufs 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, 24 Oct 2005 09:50:34 -0000 kamal kc wrote: > - final thing does this makes any difference > (calling the htons() twice): > > ip->ip_id=htons(ip->ip_id); > ip->ip_id=htons(ip->ip_id); on little endian machines: yes. on big endian machines: no. So don't do it. :) freebsd has several fields of the ip headerin host byte order to speed up access. they get converted to network byte order at a very late stage of the ip output path. cheers simon -- Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\ Work - Mac +++ space for low $$$ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ From owner-freebsd-net@FreeBSD.ORG Mon Oct 24 11:02: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 E27D516A41F for ; Mon, 24 Oct 2005 11:02:12 +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 492AC43D5C for ; Mon, 24 Oct 2005 11:02:12 +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.3/8.13.3) with ESMTP id j9OB2CXp062033 for ; Mon, 24 Oct 2005 11:02:12 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j9OB2BBK062027 for freebsd-net@freebsd.org; Mon, 24 Oct 2005 11:02:11 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 24 Oct 2005 11:02:11 GMT Message-Id: <200510241102.j9OB2BBK062027@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, 24 Oct 2005 11:02:13 -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 1 problem total. From owner-freebsd-net@FreeBSD.ORG Mon Oct 24 13:23:33 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 EE1DB16A41F; Mon, 24 Oct 2005 13:23:33 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EE8E43D72; Mon, 24 Oct 2005 13:23:23 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from lapdance.yazzy.net (unknown [192.168.99.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yazzy.org (Postfix) with ESMTP id 002ED3983D; Mon, 24 Oct 2005 15:23:19 +0200 (CEST) Date: Mon, 24 Oct 2005 13:22:36 +0000 From: Marcin Jessa To: Message-Id: <20051024132236.01e59929.lists@yazzy.org> In-Reply-To: <016201c5d845$84992820$42764eca@ilo.skyinet.net> References: <20051019235111.2225345e.lists@yazzy.org> <20051020070145.GA59364@cell.sick.ru> <20051020131549.5e432073.lists@yazzy.org> <20051020123159.33f6fa33.lists@yazzy.org> <07c501c5d5e1$0ddf67f0$42764eca@ilo.skyinet.net> <20051021112934.7c857fcc.lists@yazzy.org> <002801c5d634$fdc66bd0$42764eca@ilo.skyinet.net> <20051021145523.097758f5.lists@yazzy.org> <016201c5d845$84992820$42764eca@ilo.skyinet.net> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.2 (GTK+ 2.6.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: glebius@FreeBSD.org, net@FreeBSD.org Subject: Re: PPPoE and Radius on 6.0RC1 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, 24 Oct 2005 13:23:34 -0000 On Mon, 24 Oct 2005 10:49:13 +0800 wrote: > ----- Original Message ----- > From: "Marcin Jessa" > To: > Cc: ; ; > Sent: Friday, October 21, 2005 8:55 PM > Subject: Re: PPPoE and Radius on 6.0RC1 > > > > Thanks a lot. > > I recompiled my kernel with the netgraph options and set up the > > server with your configs. Besides from the fact that I only use my > > fxp0 in the tests. > > root 787 0.0 0.1 1256 796 ?? Ss 2:41PM > > 0:00.02 /usr/libexec/pppoed -l PPPoE -P /var/run/pppoed.pid -p * > > fxp0 > > ok... but i would like to suggest your pppoe clients must be facing > the ip less interface nic so that clients would not put static > configuration on their side to defeat your pppoe configuration :-> Yeah I know. This is just a test setup so it's ok with only one iface. > > I disabled radius as well adding username and password by > > hand. > > without radius does it worked? > > > Although the radius itself works fine when I test it with radtest > > and user's credits. > > Just like before, nothing gets loged in ppp.log and the ppp process > > itself never gets started up by the pppoe daemon. > > does your radius server supports microsoft chap version 2? my config > given to you only authenticates mschapv2... It does. Everything is working now. I have recompiled my kernel to match exactly the one I had with working PPPoE and I am set. Although I have seen a strange thing. Enabling support for chap, mschap and mschapv2 does not work at the same time. A client can connect only with chap when all the others are enabled. When I enable e.g. mschapv2 only I can login using mschapv2 just fine then. Any idea how to make ppp support all the methods at the same time so the client can chose what to use? I remember this worked fine before last I tried it on 5.x. > > "on receipt of the SUCCESS indication, pppoed > > will execute exec /usr/sbin/ppp -direct label" > > - This part is not taking place.... > > actually pppoed did executed ppp.... ppp will exit immediately if it > sees something wrong with its configuration, authentication and > others... It's working now after lots of tweaking with ppp config and kernel options. Thanks a lot. From owner-freebsd-net@FreeBSD.ORG Mon Oct 24 13:35: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 EF6B116A41F for ; Mon, 24 Oct 2005 13:35:17 +0000 (GMT) (envelope-from freebsd@azimut-tour.ru) Received: from cny.innet.yaroslavl.su (cny.innet.yaroslavl.su [217.15.134.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DCB643D48 for ; Mon, 24 Oct 2005 13:35:16 +0000 (GMT) (envelope-from freebsd@azimut-tour.ru) Received: from tac.innet.yaroslavl.su (tac.innet.yaroslavl.su [217.15.135.68]) by cny.innet.yaroslavl.su (8.11.6/8.11.6) with ESMTP id j9ODZDW26947 for ; Mon, 24 Oct 2005 17:35:14 +0400 (MSD) Received: from greencomp.azimutprint.ru (118.ppp145.yaroslavl.ru [217.15.145.118]) by tac.innet.yaroslavl.su (8.12.11/8.12.11) with ESMTP id j9ODZA9f030185 for ; Mon, 24 Oct 2005 17:35:13 +0400 (MSD) Date: Mon, 24 Oct 2005 17:35:05 +0400 From: GreenX X-Mailer: The Bat! (v3.60.07) Professional X-Priority: 3 (Normal) Message-ID: <927387823.20051024173505@azimut-tour.ru> To: freebsd-net@freebsd.org In-Reply-To: <435C68FC.9090506@roq.com> References: <20051020140200.GL59364@cell.sick.ru> <4359FFE3.7060001@roq.com> <20051022091905.GH59364@cell.sick.ru> <435B3A92.1040600@roq.com> <435C68FC.9090506@roq.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: em(4) patch for test X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "FreeBSD@azimut-tour.ru" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2005 13:35:18 -0000 =C7=E4=F0=E0=E2=F1=F2=E2=F3=E9=F2=E5 Before corrections productivity did not test, but under loading the link is down. After has added "media" and "mediaopt" in rc.conf for some days the link has not fallen never, but whether there were loadings these days I know. After a patch, copied approximately 23 Gb data in four streams on SMB there and back - all is good :) P.S. three errors have arisen because of that I have forgotten and have changed rules of the filter pf. netstat -I em0 -f link Name Mtu Network Address Ipkts Ierrs Opkts Oerrs = Coll em0 1500 00:0e:a6:5f:f2:ba 78865687 3 61640916 0 = 0 --=20 =D1 =F3=E2=E0=E6=E5=ED=E8=E5=EC, GreenX mailto:freebsd@azimut-tour.ru From owner-freebsd-net@FreeBSD.ORG Mon Oct 24 21:19:27 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 CDFA416A41F for ; Mon, 24 Oct 2005 21:19:27 +0000 (GMT) (envelope-from volker@vwsoft.com) Received: from tce71.tce85.de (tce71.tce85.de [195.145.102.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4675543D49 for ; Mon, 24 Oct 2005 21:19:24 +0000 (GMT) (envelope-from volker@vwsoft.com) Received-SPF: unknown (tce71.tce85.de: error in processing during lookup of domain of vwsoft.com: Could not find a valid SPF record) client-ip=83.242.60.134; envelope-from=volker@vwsoft.com; helo=mail.vtec.ipme.de; Received: from mail.vtec.ipme.de (134-60-242-83.dip.h-tel.de [83.242.60.134]) by tce71.tce85.de (Postfix) with ESMTP id 74DAC17092 for ; Mon, 24 Oct 2005 23:19:21 +0200 (CEST) Received: from [192.168.16.3] (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id 7F69D5C4F; Mon, 24 Oct 2005 23:19:09 +0200 (CEST) Message-ID: <435D5DDE.60000@vwsoft.com> Date: Mon, 24 Oct 2005 23:19:10 +0100 From: Volker User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Thunderbird/1.0.6 Mnenhy/0.6.0.101 X-Accept-Language: en-us, en MIME-Version: 1.0 To: VANHULLEBUS Yvan References: <435C0C3A.6070000@shrew.net> <20051024073804.GA8190@zen.inc> <435D0641.2060208@shrew.net> <20051024160822.GB28295@zen.inc> In-Reply-To: <20051024160822.GB28295@zen.inc> X-Enigmail-Version: 0.92.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-TarmacCE-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com Cc: freebsd-net@freebsd.org, Matthew Grooms Subject: Re: IPSec tcp session stalling ( me too ) ... 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, 24 Oct 2005 21:19:28 -0000 Yvan, >> 2) a gif tunnel > > No, and that's the main difference for now: I *never* used Gif > interfaces. And that's the point. When not using a gif interface to pass traffic through the IPSec tunnel, I don't see any trouble at all and everything works fine. As soon as a gif interface is involved, the tcp (haven't checked with udp) session running inside the gif tunnel breaks. When either not using IPSec, not enabling pf or not using gif - everything is fine. My setup always secured the outside of the tunnel. I haven't checked to secure the inside of the gif tunnel by using IPSec. Volker On 2005-10-24 17:08, VANHULLEBUS Yvan wrote: > On Mon, Oct 24, 2005 at 11:05:21AM -0500, Matthew Grooms wrote: > >>Yvan, >> >>VANHULLEBUS Yvan wrote: >> >> >>>We have *lots* of Gates running FreeBSD 4.11 and IPSEC (not >>>FAST_IPSEC), and I already have some 5.3 / 6.0 gates, also using >>>IPSEC. >>> >>> >>>Yvan. >>> >> >> I have a 4.11 server in production handling VPN traffic that is >>working perfectly as well. With 5.x or 6.x, my testing shows that >>traffic originating from a VPN gateway that traverses the tunnel works >>without a problem too. I only see this happen with TCP traffic, on 5.x+ >>while running a packet filter ( pf or ipfw ) and forwarding traffic >>sourced from a private network that matches the IPSEC security policy. > > > Ok. > > > >>Volker is seeing the problem with TCP traffic, when he is running 5.x+ >>while running a packet filter and forwarding gif tunnel traffic that >>matches the IPSEC security policy. > > > It really looks like we all experimented different problems (my > "problem" is the MTU issue I regulary see) which have "some common > aspects". > > > >> So, I appreciate your input by stating that your servers are not >>experiencing the same problem we are seeing. But before you dismiss the >>validity of our issue, you should be able to answer the yes to all of >>the following questions. > > > I don't dismiss anything, just telling that this not a "global IPSec > issue", but "something more specific". My first idea was the MTU > issue, it looks like it's not that. > > > >>Are you ... >> >>A) Running 5.x or 6.x > > > 6.0 on at least one production gate, and we are starting to do heavy > tests on some 5.4 gates (yes, I know, this can look strange, but the > 6.0 Gate is not related to our global "production"). > > > >>B) Running a packet filter > > > Pf on the 6.0 Gate, specific packet filter on 4.11 / 5.4 products. > > > >>C) Protecting traffic being forwarded from either >> 1) a private network > > > Yes > > >> 2) a gif tunnel > > > No, and that's the main difference for now: I *never* used Gif > interfaces. > > > >>D) Sending TCP traffic > > > I can answer "sending lots of TCP traffic, including, for example, > some large (lots of Mb) scp file transferts". > > > > Yvan. > From owner-freebsd-net@FreeBSD.ORG Mon Oct 24 22:23:58 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 CF8F816A41F for ; Mon, 24 Oct 2005 22:23:58 +0000 (GMT) (envelope-from volker@vwsoft.com) Received: from tce71.tce85.de (tce71.tce85.de [195.145.102.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55D0543D45 for ; Mon, 24 Oct 2005 22:23:58 +0000 (GMT) (envelope-from volker@vwsoft.com) Received-SPF: unknown (tce71.tce85.de: error in processing during lookup of domain of vwsoft.com: Could not find a valid SPF record) client-ip=83.242.61.87; envelope-from=volker@vwsoft.com; helo=mail.vtec.ipme.de; Received: from mail.vtec.ipme.de (87-61-242-83.dip.h-tel.de [83.242.61.87]) by tce71.tce85.de (Postfix) with ESMTP id A1F4417092 for ; Tue, 25 Oct 2005 00:23:51 +0200 (CEST) Received: from [192.168.16.3] (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id 0B2D85C4E for ; Tue, 25 Oct 2005 00:07:43 +0200 (CEST) Message-ID: <435D693F.5090502@vwsoft.com> Date: Tue, 25 Oct 2005 00:07:43 +0100 From: Volker User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Thunderbird/1.0.6 Mnenhy/0.6.0.101 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.92.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-TarmacCE-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com Subject: more on IPSec + gif stalling 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, 24 Oct 2005 22:23:58 -0000 Hi guys! I've done another test on the IPSec + gif issue. Here at my home network I'm running a RELENG_6 box and I've also just setup a 2nd test server (RELEASE_5_4). Both are connected by a direct 100 MBit/s LAN connection. Set up IPSec rules for both machines, created a gif tunnel between both and send traffic through the tunnel and the result is the same. As soon as some amount of data (somewhat around 56k to 64k) has been transferred through the gif tunnel, the transfer session stalls. When not using a gif tunnel over IPSec, everything is fine. This means: IPSec + gif + firewall (pf) = tcp sessions within the gif tunnel stalls IPSec + gif - firewall = just works IPSec - gif + firewall = just works -IPSec + gif + firewall = just works In my test scenario I've secured the outside of the gif tunnel by IPSec. I haven't checked what happens when the inside of the gif tunnel is being secured by IPSec. Also I've checked with both kernel options IPSEC and FAST_IPSEC. It didn't make a difference. I've checked the inside of the gif tunnel and the outside for suspicious packets but couldn't find one. I've checked for IPSec tunnel mode and transport mode and as soon as I'm using a gif tunnel, a data session running inside the gif tunnel dies sooner or later (transport/tunnel does not make any difference to this issue). When disabling the firewall (pf) at the __senders' side__ (important!) the data transfer does not stall. Nothing is being blocked by the firewall (tripple checked). It's not just pf as ipfw is being reported to the same effect. pf 'scrub' rules doesn't make any difference (tested with and without scrubbing). Really, I don't believe this is an MTU issue. In my test scenario I've two hosts directly connected via ethernet (100BaseT), MTU = 1500, gif MTU = 1280, no router between. If somebody else is using a gif tunnel over IPSec on a recent release (RELENG_5/6, RELEASE_5_x) plus firewall, please provide me (by private email) with your kernel config, racoon.conf and your ipsec rules. That way I might check out different kernel settings and test that out here using my test setup. When talking about 'tcp session within the gif tunnel': I haven't checked if this also happens to udp. I've checked tcp sessions through the gif tunnel by scp and a plain ascii transfer by using (g)netcat. Matthew and me have dealt out to test an IPSec + gif setup over the public internet one more time. I bet this will show the stalling, too. bye, Volker From owner-freebsd-net@FreeBSD.ORG Tue Oct 25 02:41:45 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 D6A6A16A421; Tue, 25 Oct 2005 02:41:45 +0000 (GMT) (envelope-from david.mao@thomson.net) Received: from dmzraw5.extranet.tce.com (dmzraw5.extranet.tce.com [157.254.234.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id D364243D49; Tue, 25 Oct 2005 02:41:44 +0000 (GMT) (envelope-from david.mao@thomson.net) Received: from indyvss2.am.thmulti.com (unknown [157.254.92.61]) by dmzraw5.extranet.tce.com (Postfix) with ESMTP id 9C8D2D04; Tue, 25 Oct 2005 02:41:43 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by indyvss2.am.thmulti.com (Postfix) with ESMTP id 91DA27FB30; Tue, 25 Oct 2005 02:41:43 +0000 (GMT) Received: from indyvss2.am.thmulti.com ([127.0.0.1]) by localhost (indyvss2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 22302-01-23; Tue, 25 Oct 2005 02:41:39 +0000 (GMT) Received: from smtprelay2.indy.tce.com (smtprelay2.indy.tce.com [157.254.96.95]) by indyvss2.am.thmulti.com (Postfix) with ESMTP id AB7E67FB3A; Tue, 25 Oct 2005 02:41:39 +0000 (GMT) Received: from boulsmailbh01.eu.thmulti.com (localhost [127.0.0.1]) by smtprelay2.indy.tce.com (8.12.9/8.12.8) with ESMTP id j9P2fWH8023536; Tue, 25 Oct 2005 02:41:38 GMT Received: from TAHKSMAILBH01.ap.thmulti.com ([141.11.13.33]) by boulsmailbh01.eu.thmulti.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2005 04:41:37 +0200 Received: from bjngsmail01.ap.thmulti.com ([10.11.70.35]) by TAHKSMAILBH01.ap.thmulti.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2005 10:41:30 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Oct 2005 10:41:28 +0800 Message-ID: <31021C278A7A6B4AB95E9A085C355218284807@bjngsmail01> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: em(4) patch for test Thread-Index: AcXVfumq1ejX6UASRwalBtcMTajGuQDjnsog From: "Mao Shou Yan" To: "Gleb Smirnoff" , X-OriginalArrivalTime: 25 Oct 2005 02:41:30.0869 (UTC) FILETIME=[9B078250:01C5D90D] X-Virus-Scanned: amavisd-new at thomson.net Cc: Subject: RE: em(4) patch for test 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, 25 Oct 2005 02:41:46 -0000 Can we patch it against 4.11? If not, can we patch the em_intr() to 4.11?=20 Is this patch useful to 4.11? Thanks! David.Mao -----Original Message----- From: owner-freebsd-net@freebsd.org = [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Gleb Smirnoff Sent: 2005=C4=EA10=D4=C220=C8=D5 22:02 To: net@FreeBSD.org Subject: em(4) patch for test Colleagues, since the if_em problem was taken as a late showstopper for = 6.0-RELEASE, I am asking you to help with testing of the fixes made in HEAD. Does your em(4) interface wedge for some time? Do you see a lot of errors in 'netstat -i' output? Does these errors increase not monotonously but they have peaks? If the answer is yes, then the attached patch is likely to fix your = problem. If the answer is no, then you are still encouraged to help with testing and install the patch to check that no regressions are introduced. If = you skip this, then you may encounter regressions after release, so you have been warned. So, in short: please test! Thanks in advance! The patch is against fresh RELENG_6. --=20 Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Oct 25 05:00:51 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 9AAAF16A424; Tue, 25 Oct 2005 05:00:51 +0000 (GMT) (envelope-from fooler@skyinet.net) Received: from smtp2.skyinet.net (smtp2.skyinet.net [202.78.97.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A3BE43D5D; Tue, 25 Oct 2005 05:00:47 +0000 (GMT) (envelope-from fooler@skyinet.net) Received: from fooler (fooler.ilo.skyinet.net [202.78.118.66]) by smtp2.skyinet.net (Postfix) with SMTP id C4B685BA43; Tue, 25 Oct 2005 13:00:45 +0800 (PHT) Message-ID: <04b701c5d921$1066ae00$42764eca@ilo.skyinet.net> From: To: "Marcin Jessa" References: <20051019235111.2225345e.lists@yazzy.org><20051020070145.GA59364@cell.sick.ru><20051020131549.5e432073.lists@yazzy.org><20051020123159.33f6fa33.lists@yazzy.org><07c501c5d5e1$0ddf67f0$42764eca@ilo.skyinet.net><20051021112934.7c857fcc.lists@yazzy.org><002801c5d634$fdc66bd0$42764eca@ilo.skyinet.net><20051021145523.097758f5.lists@yazzy.org><016201c5d845$84992820$42764eca@ilo.skyinet.net> <20051024132236.01e59929.lists@yazzy.org> Date: Tue, 25 Oct 2005 13:00:47 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Cc: brian@Awfulhak.org, glebius@FreeBSD.org, net@FreeBSD.org Subject: Re: PPPoE and Radius on 6.0RC1 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, 25 Oct 2005 05:00:52 -0000 ----- Original Message ----- From: "Marcin Jessa" To: Cc: ; Sent: Monday, October 24, 2005 9:22 PM Subject: Re: PPPoE and Radius on 6.0RC1 > It does. Everything is working now. good to hear that :-> > Any idea how to make ppp support all the methods at the same time so > the client can chose what to use? just enable those parameters instead of disable it... but still the client is the one choosing what kind of authentication takes place... but i still strongly advise to use mschapv2 instead of pap, chap and mschapv1 for security purposes both for wired and wireless pppoe authentication... > It's working now after lots of tweaking with ppp config and kernel > options. > Thanks a lot. one important side note especially if you are using radius for your pppoe authentication and the radius accounting server is at remote location... after the client disconnects... ppp will just simply send *one* accounting packet without waiting for the reply from radius accounting server for acknowledgement and exit immediately... this will affect your proper accounting and single login policy because the radius server still think that the user is still online... brian, to whom we will contact to fix this problem? thanks... fooler. From owner-freebsd-net@FreeBSD.ORG Tue Oct 25 06:50:19 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 1496D16A420 for ; Tue, 25 Oct 2005 06:50: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 52A3043D45 for ; Tue, 25 Oct 2005 06:50: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 j9P6oFYJ071286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Oct 2005 10:50:15 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j9P6oEJx071285; Tue, 25 Oct 2005 10:50:14 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 25 Oct 2005 10:50:14 +0400 From: Gleb Smirnoff To: Mao Shou Yan Message-ID: <20051025065014.GY41520@cell.sick.ru> References: <31021C278A7A6B4AB95E9A085C355218284807@bjngsmail01> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <31021C278A7A6B4AB95E9A085C355218284807@bjngsmail01> User-Agent: Mutt/1.5.6i Cc: net@FreeBSD.org Subject: Re: em(4) patch for test 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, 25 Oct 2005 06:50:19 -0000 On Tue, Oct 25, 2005 at 10:41:28AM +0800, Mao Shou Yan wrote: M> Can we patch it against 4.11? M> If not, can we patch the em_intr() to 4.11? M> Is this patch useful to 4.11? I don't think so. Do you encounter a lot if input errors on 4.11? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Oct 25 06:55: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 73EFA16A424; Tue, 25 Oct 2005 06:55:13 +0000 (GMT) (envelope-from david.mao@thomson.net) Received: from dmzraw5.extranet.tce.com (dmzraw5.extranet.tce.com [157.254.234.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4097E43D45; Tue, 25 Oct 2005 06:55:12 +0000 (GMT) (envelope-from david.mao@thomson.net) Received: from dmzraw4.extranet.tce.com (dmzraw4.extranet.tce.com [157.254.234.139]) by dmzraw5.extranet.tce.com (Postfix) with ESMTP id 6B917B1D; Tue, 25 Oct 2005 06:55:11 +0000 (GMT) Received: from indyvss3.am.thmulti.com (unknown [157.254.92.62]) by dmzraw4.extranet.tce.com (Postfix) with ESMTP id 65B111148; Tue, 25 Oct 2005 06:55:11 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by indyvss3.am.thmulti.com (Postfix) with ESMTP id 5A619BA41; Tue, 25 Oct 2005 06:55:11 +0000 (GMT) Received: from indyvss3.am.thmulti.com ([127.0.0.1]) by localhost (indyvss3 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 07850-01-90; Tue, 25 Oct 2005 06:55:08 +0000 (GMT) Received: from indysmailcs01.am.thmulti.com (indysmailcs01.am.thmulti.com [157.254.96.5]) by indyvss3.am.thmulti.com (Postfix) with ESMTP id 7B59EBA43; Tue, 25 Oct 2005 06:55:08 +0000 (GMT) Received: from indysmailbh01.am.thmulti.com ([157.254.96.4]) by indysmailcs01.am.thmulti.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2005 01:55:08 -0500 Received: from tahkexch2k.ap.thmulti.com ([141.11.13.12]) by indysmailbh01.am.thmulti.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2005 01:55:08 -0500 Received: from bjngsmail01.ap.thmulti.com ([10.11.70.35]) by tahkexch2k.ap.thmulti.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Oct 2005 14:55:04 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Oct 2005 14:55:01 +0800 Message-ID: <31021C278A7A6B4AB95E9A085C35521828495B@bjngsmail01> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: em(4) patch for test Thread-Index: AcXZMGNg+KtvnHgdSoOsGh4NzXiG+wAABwSw From: "Mao Shou Yan" To: "Gleb Smirnoff" X-OriginalArrivalTime: 25 Oct 2005 06:55:04.0714 (UTC) FILETIME=[073006A0:01C5D931] X-Virus-Scanned: amavisd-new at thomson.net Cc: net@FreeBSD.org Subject: RE: em(4) patch for test 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, 25 Oct 2005 06:55:13 -0000 NO, I didn't encounter a lot if input errors on 4.11. But I met a lot if input errors on 5.4. And I don't know why? Is this for so many CSWs( systat -vmstat 1) or any other reason? BTW, New patch loops in em_intr() like linux' NAPI. If we apply new patch, polling is necessary yet? David.Mao -----Original Message----- From: Gleb Smirnoff [mailto:glebius@FreeBSD.org]=20 Sent: 2005=C4=EA10=D4=C225=C8=D5 14:50 To: Mao Shou Yan Cc: net@FreeBSD.org Subject: Re: em(4) patch for test On Tue, Oct 25, 2005 at 10:41:28AM +0800, Mao Shou Yan wrote: M> Can we patch it against 4.11? M> If not, can we patch the em_intr() to 4.11?=20 M> Is this patch useful to 4.11? I don't think so. Do you encounter a lot if input errors on 4.11? --=20 Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Oct 25 07:05:10 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 71A2B16A41F for ; Tue, 25 Oct 2005 07:05:10 +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 99C7843D48 for ; Tue, 25 Oct 2005 07:05:09 +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 j9P757ZD071714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Oct 2005 11:05:08 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j9P757qL071713; Tue, 25 Oct 2005 11:05:07 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 25 Oct 2005 11:05:07 +0400 From: Gleb Smirnoff To: Mao Shou Yan Message-ID: <20051025070507.GA41520@cell.sick.ru> References: <31021C278A7A6B4AB95E9A085C35521828495B@bjngsmail01> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <31021C278A7A6B4AB95E9A085C35521828495B@bjngsmail01> User-Agent: Mutt/1.5.6i Cc: net@FreeBSD.org Subject: Re: em(4) patch for test 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, 25 Oct 2005 07:05:10 -0000 On Tue, Oct 25, 2005 at 02:55:01PM +0800, Mao Shou Yan wrote: M> NO, I didn't encounter a lot if input errors on 4.11. M> But I met a lot if input errors on 5.4. And I don't know why? M> Is this for so many CSWs( systat -vmstat 1) or any other reason? M> BTW, New patch loops in em_intr() like linux' NAPI. If we apply new M> patch, polling is necessary yet? If you encounter problems on 5.4, then you should try the patch. The patch doesn't affects polling users, only those who use interrupt driven mode. P.S. Please don't top quote. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Oct 25 07:28:38 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 2D9F016A41F for ; Tue, 25 Oct 2005 07:28:38 +0000 (GMT) (envelope-from silby@silby.com) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 8118043D49 for ; Tue, 25 Oct 2005 07:28:37 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 55692 invoked from network); 25 Oct 2005 07:28:35 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 25 Oct 2005 07:28:35 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 25 Oct 2005 02:28:33 -0500 (CDT) From: Mike Silbersack To: Anton Bester In-Reply-To: <200510181954020250.00A66152@196.25.53.68> Message-ID: <20051025022412.X911@odysseus.silby.com> References: <200510181954020250.00A66152@196.25.53.68> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Bind 8 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, 25 Oct 2005 07:28:38 -0000 On Tue, 18 Oct 2005, Anton Bester wrote: > Hi All, > > I do not know if this is the correct forum for this questions, if not please point me in the right direction. > > My secondary DNS server all of a sudden started to chop up about 100% of > my server's cpu, I'm running a FreeBSD 5.1-RELEASE server with Bind 8. > It was doning fine until I noticed that the sever's cpu running near > 100%, it turned out to be bind. > > When I restart bind it takes a couple of minutes but then it is back at > 70% - 100% with a lot of traffic being send to my primary DNS server, I > have noticed the following error in the Primary DNS log file: > > Oct 18 12:24:01 ns /kernel: Limiting icmp unreach response from 315 to 200 packets per second > Oct 18 12:24:02 ns /kernel: Limiting icmp unreach response from 259 to 200 packets per second > Oct 18 12:24:03 ns /kernel: Limiting icmp unreach response from 223 to 200 packets per second The problems may or may not be related, a good tcpdump will be required to figure it out. Those messages appear when incoming UDP packets are destined to a port that isn't listening for responses. DNS can cause that in two ways that I can think of off the top of my head: 1. A client program makes a DNS request to DNS server. The DNS server takes a long time responding, and in the meantime the client gives up and stops listening for a response. The DNS server finally returns a response, but since the client is no longer listening, the kernel has to return an icmp unreach response. 2. Similar case - you restart DNS server A, which had a bunch of queries in to DNS server B. DNS server A is restarted, and listens for query responses on a different port than it did before. DNS B responds with all the delayed DNS responses, and the kernel has to bounce all 315 per second of them. So, BIND is the real problem here, those messages are just telling you that the kernel is limiting the number of "icmp unreach" messages to packets who have no real destination anymore. This is mostly to save bandwidth during DoS attacks. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Tue Oct 25 08:25:11 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 1C28C16A426; Tue, 25 Oct 2005 08:25:11 +0000 (GMT) (envelope-from david.mao@thomson.net) Received: from dmzraw5.extranet.tce.com (dmzraw5.extranet.tce.com [157.254.234.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57D3F43D4C; Tue, 25 Oct 2005 08:25:10 +0000 (GMT) (envelope-from david.mao@thomson.net) Received: from indyvss3.am.thmulti.com (unknown [157.254.92.62]) by dmzraw5.extranet.tce.com (Postfix) with ESMTP id 8885E1024; Tue, 25 Oct 2005 08:25:09 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by indyvss3.am.thmulti.com (Postfix) with ESMTP id 70C9F1623C; Tue, 25 Oct 2005 08:25:09 +0000 (GMT) Received: from indyvss3.am.thmulti.com ([127.0.0.1]) by localhost (indyvss3 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14310-01-59; Tue, 25 Oct 2005 08:25:04 +0000 (GMT) Received: from indysmailcs01.am.thmulti.com (indysmailcs01.am.thmulti.com [157.254.96.5]) by indyvss3.am.thmulti.com (Postfix) with ESMTP id 8F8281624C; Tue, 25 Oct 2005 08:25:04 +0000 (GMT) Received: from INDYSMAILBH02.am.thmulti.com ([157.254.96.2]) by indysmailcs01.am.thmulti.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2005 03:25:04 -0500 Received: from tahkexch2k.ap.thmulti.com ([141.11.13.12]) by INDYSMAILBH02.am.thmulti.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2005 03:25:04 -0500 Received: from bjngsmail01.ap.thmulti.com ([10.11.70.35]) by tahkexch2k.ap.thmulti.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Oct 2005 16:25:01 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Oct 2005 16:24:59 +0800 Message-ID: <31021C278A7A6B4AB95E9A085C3552182849EF@bjngsmail01> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: em(4) patch for test Thread-Index: AcXZMnXrZVy9IbkUQJmPK3ZzkLctGgACp25w From: "Mao Shou Yan" To: "Gleb Smirnoff" X-OriginalArrivalTime: 25 Oct 2005 08:25:01.0223 (UTC) FILETIME=[97C1F370:01C5D93D] X-Virus-Scanned: amavisd-new at thomson.net Cc: net@FreeBSD.org Subject: RE: em(4) patch for test 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, 25 Oct 2005 08:25:11 -0000 On Tue, Oct 25, 2005 at 02:55:01PM +0800, Mao Shou Yan wrote: M> NO, I didn't encounter a lot if input errors on 4.11. M> But I met a lot if input errors on 5.4. And I don't know why? M> Is this for so many CSWs( systat -vmstat 1) or any other reason? M> BTW, New patch loops in em_intr() like linux' NAPI. If we apply new M> patch, polling is necessary yet? >>If you encounter problems on 5.4, then you should try the patch. >>The patch doesn't affects polling users, only those who use >>interrupt driven mode. >>P.S. Please don't top quote. Several weeks ago, I setup an 5.4 and enable polling by using em(4). There were a lot if input errors. The problem was not resolved yet. --=20 Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Oct 25 13:58: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 6BEF716A41F for ; Tue, 25 Oct 2005 13:58:40 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05E7D43D5D for ; Tue, 25 Oct 2005 13:58:39 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by smtp2-g19.free.fr (Postfix) with ESMTP id 1DCE4521B4; Tue, 25 Oct 2005 15:58:38 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 90445405A; Tue, 25 Oct 2005 15:58:17 +0200 (CEST) Date: Tue, 25 Oct 2005 15:58:17 +0200 From: Jeremie Le Hen To: VANHULLEBUS Yvan Message-ID: <20051025135817.GN14063@obiwan.tataz.chchile.org> References: <4358082A.4060409@vwsoft.com> <43581E7F.5080305@vwsoft.com> <20051021071039.GA1876@zen.inc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051021071039.GA1876@zen.inc> User-Agent: Mutt/1.5.10i Cc: freebsd-net@freebsd.org Subject: Re: IPSec session stalls 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, 25 Oct 2005 13:58:40 -0000 > Not sure: what you described in your first mail also looks like a > "basic" fragmentation problem, which can be easily solved by > decreasing MTU on traffic endpoints (you can also play with TCPMSS on > one gate, but this will only solve TCP problems...). > > The pf interaction may only be a side effect of a fragmentation > problem. Hi also have problems with my IPSec tunnel. IIRC from tests that I made, this is a Path MTU Discovery problem. I described a similar problem here, but never succeeded to resolve it, unfortunately. Note that I didn't use pf. It is described here : http://lists.freebsd.org/pipermail/freebsd-net/2005-July/007899.html Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Tue Oct 25 16:04:35 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 17D7816A41F for ; Tue, 25 Oct 2005 16:04:35 +0000 (GMT) (envelope-from kfl@xiplink.com) Received: from mail.net (custpop.ca.mci.com [142.77.1.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id E303D43D76 for ; Tue, 25 Oct 2005 16:04:33 +0000 (GMT) (envelope-from kfl@xiplink.com) Received: from [216.95.199.148] (account kfl@xiphos.ca HELO [192.168.1.7]) by mail.net (CommuniGate Pro SMTP 4.2.8) with ESMTP id 84951346 for freebsd-net@freebsd.org; Tue, 25 Oct 2005 12:04:32 -0400 Message-ID: <435E5980.6000200@xiplink.com> Date: Tue, 25 Oct 2005 12:12:48 -0400 From: Karim Fodil-Lemelin User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Release 6.0 TCP stack 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, 25 Oct 2005 16:04:35 -0000 Hello, I just noticed that RELENG_6 was frozen, I haven't downloaded the RC1 yet but I have BETA4 and noticed that T/TCP was removed and a blank was left in its place. I would like to know if there will be a replacement for T/TCP in FreeBSD 6.0 STABLE or not. Thanks, PS: Nice work on the new FreeBSD project web site, things are much easier to find now. -- Karim From owner-freebsd-net@FreeBSD.ORG Tue Oct 25 16:33: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 D684916A41F for ; Tue, 25 Oct 2005 16:33:05 +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 2681443D53 for ; Tue, 25 Oct 2005 16:33:04 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 74243 invoked from network); 25 Oct 2005 16:37:36 -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 ; 25 Oct 2005 16:37:36 -0000 Message-ID: <435E5E40.B55FB597@freebsd.org> Date: Tue, 25 Oct 2005 18:33:04 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Karim Fodil-Lemelin References: <435E5980.6000200@xiplink.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Release 6.0 TCP stack 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, 25 Oct 2005 16:33:06 -0000 Karim Fodil-Lemelin wrote: > > Hello, > > I just noticed that RELENG_6 was frozen, I haven't downloaded the > RC1 yet but I have BETA4 and noticed that T/TCP was removed and a blank > was left in its place. I would like to know if there will be a > replacement for T/TCP in FreeBSD 6.0 STABLE or not. The T/TCP replacement will be in FreeBSD 7 (aka -current) before end of the year. After some time settling in it is very likely to get backported to be released in FreeBSD 6.1 as it doesn't break API/ABI compatibility. > Thanks, > > PS: Nice work on the new FreeBSD project web site, things are much > easier to find now. Thanks. It was a big thing that kept many in the FreeBSD team busy for quite some time. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Oct 25 16:47: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 87B3816A420; Tue, 25 Oct 2005 16:47:54 +0000 (GMT) (envelope-from howells@kde.org) Received: from mail.devrandom.org.uk (host-84-9-223-82.bulldogdsl.com [84.9.223.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C79643D5C; Tue, 25 Oct 2005 16:47:46 +0000 (GMT) (envelope-from howells@kde.org) Received: from localhost (localhost [127.0.0.1]) by mail.devrandom.org.uk (Postfix) with ESMTP id 7A1C8FD0A8; Tue, 25 Oct 2005 17:47:45 +0100 (BST) Received: from mail.devrandom.org.uk ([127.0.0.1]) by localhost (mail.devrandom.org.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81720-04; Tue, 25 Oct 2005 17:47:41 +0100 (BST) Received: from [192.168.1.190] (unknown [192.168.1.190]) by mail.devrandom.org.uk (Postfix) with ESMTP id 85585FD0A5; Tue, 25 Oct 2005 17:47:41 +0100 (BST) Message-ID: <435E61AD.8040408@kde.org> Date: Tue, 25 Oct 2005 17:47:41 +0100 From: Chris Howells User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gleb Smirnoff , freebsd-net@freebsd.org References: <31021C278A7A6B4AB95E9A085C355218284807@bjngsmail01> <20051025065014.GY41520@cell.sick.ru> In-Reply-To: <20051025065014.GY41520@cell.sick.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at devrandom.org.uk Cc: Subject: Re: em(4) patch for test 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, 25 Oct 2005 16:47:54 -0000 Gleb Smirnoff wrote: > I don't think so. Do you encounter a lot if input errors on 4.11? > I get the wedgeing problem on a 4.11-STABLE, I have to 'ifconfig down; ifconfig up' to get it to communicate again. The system is: -bash-2.05b$ uname -a FreeBSD elrond.devrandom.org.uk 4.11-STABLE FreeBSD 4.11-STABLE #2: Mon Aug 15 00:23:05 BST 2005 root@elrond.devrandom.org.uk:/usr/obj/usr/src/sys/ELROND i386 -bash-2.05b$ uptime 5:45PM up 36 days, 23:44, 1 user, load averages: 0.00, 0.00, 0.00 Though netstat -i shows no errors: -bash-2.05b$ netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll em0 1500 00:0e:0c:77:46:58 80272921 0 123296851 0 0 em0 1500 192.168.1 elrond 79993962 - 123288983 - - em0 1500 fe80:1::20e fe80:1::20e:cff:f 0 - 2 - - vr0* 1500 00:11:d8:09:16:81 0 0 0 0 0 lp0* 1500 0 0 0 0 0 faith 1500 0 0 0 0 0 lo0 16384 53 0 53 0 0 lo0 16384 localhost ::1 0 - 0 - - lo0 16384 fe80:5::1 fe80:5::1 0 - 0 - - lo0 16384 your-net localhost 51 - 51 - - ppp0* 1500 0 0 0 0 0 sl0* 552 0 0 0 0 0 From owner-freebsd-net@FreeBSD.ORG Wed Oct 26 14:15: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 0799216A41F; Wed, 26 Oct 2005 14:15:05 +0000 (GMT) (envelope-from saundersconsult@hotmail.com) Received: from hotmail.com (bay101-dav10.bay101.hotmail.com [64.4.56.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BFB443D4C; Wed, 26 Oct 2005 14:15:04 +0000 (GMT) (envelope-from saundersconsult@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 26 Oct 2005 07:15:04 -0700 Message-ID: Received: from 24.205.176.247 by BAY101-DAV10.phx.gbl with DAV; Wed, 26 Oct 2005 14:15:03 +0000 X-Originating-IP: [24.205.176.247] X-Originating-Email: [saundersconsult@hotmail.com] X-Sender: saundersconsult@hotmail.com From: "Shawn Saunders" To: "Gleb Smirnoff" References: <4357D95C.3080903@freemail.gr> <20051021053228.GX59364@cell.sick.ru> Date: Wed, 26 Oct 2005 07:15:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="KOI8-R"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-OriginalArrivalTime: 26 Oct 2005 14:15:04.0191 (UTC) FILETIME=[A8EA48F0:01C5DA37] Cc: dionch@freemail.gr, freebsd-net@FreeBSD.org Subject: Re: Trying to make a Host into a gigabit hub for testing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Shawn Saunders List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 14:15:05 -0000 Actually, I think one2many is more appropriate. I do not want the traffic that is coming in on the incoming ports to be echoed back to them, and isn't that what the ng_hub would do? Shawn ----- Original Message ----- From: "Gleb Smirnoff" To: "Shawn Saunders" Cc: ; Sent: Thursday, October 20, 2005 10:32 PM Subject: Re: Trying to make a Host into a gigabit hub for testing > On Thu, Oct 20, 2005 at 09:31:15PM +0000, Shawn Saunders wrote: > S> Chris, > S> > S> Now the traffic is going out all the ports, thanks. Only one issue, is > S> that it is also being echo'd back the em0 interface. When I put this > under > S> a full GIGABIT load, 6 interfaces feeding back what was just sent them, > S> will kill my primary em0 interface. > S> > S> Is there a way to make the echo from em0 to all other interfaces only > go > S> one-way, rather than em0 also being part of the group and receiving > S> everthing it sends back again? > > I haven't yet understood the graph you built, but the Subject line > tells me that you should use ng_hub(4), not ng_one2many(4) or ng_fec(4). > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > _______________________________________________ > 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 Oct 26 14:17: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 D72CA16A41F for ; Wed, 26 Oct 2005 14:17:36 +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 2C3A143D48 for ; Wed, 26 Oct 2005 14:17:35 +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 j9QEHX4L096284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Oct 2005 18:17:34 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j9QEHXgi096283; Wed, 26 Oct 2005 18:17:33 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 26 Oct 2005 18:17:33 +0400 From: Gleb Smirnoff To: Shawn Saunders Message-ID: <20051026141733.GI41520@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Shawn Saunders , dionch@freemail.gr, freebsd-net@FreeBSD.org References: <20051021053228.GX59364@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Cc: dionch@freemail.gr, freebsd-net@FreeBSD.org Subject: Re: Trying to make a Host into a gigabit hub for testing 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, 26 Oct 2005 14:17:37 -0000 On Wed, Oct 26, 2005 at 07:15:18AM -0700, Shawn Saunders wrote: S> Actually, I think one2many is more appropriate. I do not want the traffic S> that is coming in on the incoming ports to be echoed back to them, and S> isn't that what the ng_hub would do? No, it wouldn't. It will send to all ports except of the port the packet was received on. P.S. Please do not top quote. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Oct 26 19:51:50 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 00D2B16A41F; Wed, 26 Oct 2005 19:51:50 +0000 (GMT) (envelope-from michael@gargantuan.com) Received: from phoenix.gargantuan.com (srv01.lak.lwxdatacom.net [24.73.171.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C91D43D45; Wed, 26 Oct 2005 19:51:49 +0000 (GMT) (envelope-from michael@gargantuan.com) Received: from localhost (localhost.gargantuan.com [127.0.0.1]) by spamassassin-injector (Postfix) with SMTP id 37DA840F; Wed, 26 Oct 2005 15:51:48 -0400 (EDT) X-Spam-DCC: : X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on phoenix.gargantuan.com X-Spam-Level: X-Spam-Status: No, score=-103.6 required=5.0 tests=AWL,BAYES_00,NO_RELAYS, USER_IN_WHITELIST autolearn=ham version=3.1.0 X-Spam-Pyzor: Received: by phoenix.gargantuan.com (Postfix, from userid 1001) id 0CAEF4AC; Wed, 26 Oct 2005 15:51:33 -0400 (EDT) Date: Wed, 26 Oct 2005 15:51:32 -0400 From: "Michael W. Oliver" To: Gleb Smirnoff , Shawn Saunders , dionch@freemail.gr, freebsd-net@FreeBSD.org Message-ID: <20051026195132.GI89629@gargantuan.com> Mail-Followup-To: Gleb Smirnoff , Shawn Saunders , dionch@freemail.gr, freebsd-net@FreeBSD.org References: <20051021053228.GX59364@cell.sick.ru> <20051026141733.GI41520@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bFsKbPszpzYNtEU6" Content-Disposition: inline In-Reply-To: <20051026141733.GI41520@cell.sick.ru> X-WWW-URL: http://michael.gargantuan.com X-GPG-PGP-Public-Key: http://michael.gargantuan.com/gnupg/pubkey.asc X-GPG-PGP-Fingerprint: 2694 0179 AE3F BFAE 0916 0BF5 B16B FBAB C5FA A3C9 X-Home-Phone: +1-863-816-8091 X-Mobile-Phone: +1-863-738-2334 X-Mailing-Address0: 8008 Apache Lane X-Mailing-Address1: Lakeland, FL X-Mailing-Address2: 33810-2172 X-Mailing-Address3: United States of America X-Guide-Questions: http://www.catb.org/~esr/faqs/smart-questions.html X-Guide-Netiquette: http://www.ietf.org/rfc/rfc1855.txt User-Agent: mutt-ng/devel-r445 (FreeBSD) Cc: Subject: Top Posting (was Re: Trying to make a Host into a gigabit hub for testing) 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, 26 Oct 2005 19:51:50 -0000 --bFsKbPszpzYNtEU6 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2005-10-26T18:17:33+0400, Gleb Smirnoff wrote: > On Wed, Oct 26, 2005 at 07:15:18AM -0700, Shawn Saunders wrote: > S> Actually, I think one2many is more appropriate. I do not want the tra= ffic=20 > S> that is coming in on the incoming ports to be echoed back to them, and= =20 > S> isn't that what the ng_hub would do? >=20 > No, it wouldn't. It will send to all ports except of the port the > packet was received on. >=20 > P.S. Please do not top quote. For those unfortunate users who are stuck with broken MUAs like Outlook or Outlook Express, please investigate the use of QuoteFix for those two particular applications. http://home.in.tum.de/~jain/software/oe-quotefix/ http://home.in.tum.de/~jain/software/outlook-quotefix/ It makes life a lot easier on those of us who read email via plain-text. If you are _slightly_ more adventurous, start using mutt! ;-) --=20 Mike Oliver [see complete headers for contact information] --bFsKbPszpzYNtEU6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDX95EsWv7q8X6o8kRArd/AKCy4Zd+JgtQdtGkzfA91mAxpAWv/ACfX8jZ 1V/yzQCMxY6vPjRMjt3CQL8= =PPz9 -----END PGP SIGNATURE----- --bFsKbPszpzYNtEU6-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 26 20:21: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 A026316A445 for ; Wed, 26 Oct 2005 20:21:41 +0000 (GMT) (envelope-from jhofer@agsense.net) Received: from mail.santel.net (mail.santel.net [12.13.116.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52AF743D49 for ; Wed, 26 Oct 2005 20:21:41 +0000 (GMT) (envelope-from jhofer@agsense.net) Received: from samara (64-33-242-135.hosts.sdnet.net [64.33.242.135] (may be forged)) by smtp1.gwtc.net (8.13.3/8.13.3) with ESMTP id j9QKLbro060884 for ; Wed, 26 Oct 2005 14:21:40 -0600 (MDT) (envelope-from jhofer@agsense.net) From: "Jordon Hofer" To: Date: Wed, 26 Oct 2005 15:21:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Subject: Cellular Modem, PPP, and FreeBSD 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, 26 Oct 2005 20:21:42 -0000 Greetings. I am running a stripped down version of FreeBSD 4.11 on an embedded x86 board. I have an embedded cellular modem module (from MultiTech) that is attached to the serial port (going through the necessary RS232-TTL chip). I am using PPP to connect to the Internet through verizon. Everything works well until the connection gets interrupted. I am using ddial mode, so if the connection drops, it will redial. From the logs, I can see that PPP tries to redial, but after the initial connection, the modem does not respond to any at commands. If I power-cycle the modem, it will connect just fine the next time PPP tries to reconnect. I realize that there is a good chance that the problem is in the modem. I am just wondering if there are any cases where you need a special chat script to handle disconnects to return the modem to a clean state. Also, if there is a better group for this, please let me know. Thanks. Jordon Hofer Dir. Software Engineering AgSense LLC From owner-freebsd-net@FreeBSD.ORG Wed Oct 26 20:46: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 2A40916A41F for ; Wed, 26 Oct 2005 20:46:13 +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 F18C143D49 for ; Wed, 26 Oct 2005 20:46:12 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.117]) ([10.251.23.117]) by a50.ironport.com with ESMTP; 26 Oct 2005 13:46:12 -0700 X-IronPort-Anti-Spam-Filtered: true Message-ID: <435FEB14.4080007@elischer.org> Date: Wed, 26 Oct 2005 13:46:12 -0700 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: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: diagram of 4.10 layer 2 spaghetti 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, 26 Oct 2005 20:46:13 -0000 at: http://people.freebsd.org/~julian/layer2b.pdf I'm going to do one for RELENG_4 by add in the bits added, and then, the big task.. one for -current BTW there is also one for the variant of 4.10 I am using at work.. http://people.freebsd.org/~julian/layer2c.pdf but it's probably not of general interest. From owner-freebsd-net@FreeBSD.ORG Wed Oct 26 22:17:45 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 DD39816A41F for ; Wed, 26 Oct 2005 22:17:45 +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 AAE6943D46 for ; Wed, 26 Oct 2005 22:17:45 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.117]) ([10.251.23.117]) by a50.ironport.com with ESMTP; 26 Oct 2005 15:17:46 -0700 X-IronPort-Anti-Spam-Filtered: true Message-ID: <43600089.4050909@elischer.org> Date: Wed, 26 Oct 2005 15:17:45 -0700 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: Julian Elischer References: <435FEB14.4080007@elischer.org> In-Reply-To: <435FEB14.4080007@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: diagram of 4.10 layer 2 spaghetti 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, 26 Oct 2005 22:17:46 -0000 I never saw this go past so I'll send it once again... maybe it looked too much like spam? I dunno. Julian Elischer wrote: > at: > > http://people.freebsd.org/~julian/layer2b.pdf > > I'm going to do one for -current > > BTW there is also one for the variant of 4.10 I am using at work.. > > http://people.freebsd.org/~julian/layer2c.pdf > > but it's probably not of general interest. > > From owner-freebsd-net@FreeBSD.ORG Wed Oct 26 22:32: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 34DC716A41F for ; Wed, 26 Oct 2005 22:32:02 +0000 (GMT) (envelope-from zec@icir.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB1E243D45 for ; Wed, 26 Oct 2005 22:32:01 +0000 (GMT) (envelope-from zec@icir.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id 7559A9B77F; Thu, 27 Oct 2005 00:31:59 +0200 (CEST) Received: from [127.0.0.1] (imunes.tel.fer.hr [161.53.19.8]) by xaqua.tel.fer.hr (Postfix) with ESMTP id A23BE9B763 for ; Thu, 27 Oct 2005 00:31:52 +0200 (CEST) From: Marko Zec To: freebsd-net@freebsd.org Date: Thu, 27 Oct 2005 00:30:12 +0200 User-Agent: KMail/1.7.2 References: <435FEB14.4080007@elischer.org> <43600089.4050909@elischer.org> In-Reply-To: <43600089.4050909@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510270030.12947.zec@icir.org> X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Subject: Re: diagram of 4.10 layer 2 spaghetti 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, 26 Oct 2005 22:32:02 -0000 On Thursday 27 October 2005 00:17, Julian Elischer wrote: > I never saw this go past so I'll send it once again... > > maybe it looked too much like spam? I dunno. No, it got through the first time as well. And I think the diagrams are quite usable indeed, thanks for providing this! Cheers, Marko > Julian Elischer wrote: > > at: > > > > http://people.freebsd.org/~julian/layer2b.pdf > > > > I'm going to do one for -current > > > > BTW there is also one for the variant of 4.10 I am using at work.. > > > > http://people.freebsd.org/~julian/layer2c.pdf > > > > but it's probably not of general interest. > > _______________________________________________ > 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 Oct 26 22:35: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 8574416A41F for ; Wed, 26 Oct 2005 22:35:43 +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 4F90F43D48 for ; Wed, 26 Oct 2005 22:35:43 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.117]) ([10.251.23.117]) by a50.ironport.com with ESMTP; 26 Oct 2005 15:35:42 -0700 X-IronPort-Anti-Spam-Filtered: true Message-ID: <436004BE.4020600@elischer.org> Date: Wed, 26 Oct 2005 15:35:42 -0700 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: Marko Zec References: <435FEB14.4080007@elischer.org> <43600089.4050909@elischer.org> <200510270030.12947.zec@icir.org> In-Reply-To: <200510270030.12947.zec@icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: diagram of 4.10 layer 2 spaghetti 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, 26 Oct 2005 22:35:43 -0000 Marko Zec wrote: >On Thursday 27 October 2005 00:17, Julian Elischer wrote: > > >>I never saw this go past so I'll send it once again... >> >>maybe it looked too much like spam? I dunno. >> >> > >No, it got through the first time as well. And I think the diagrams are >quite usable indeed, thanks for providing this! > >Cheers, > >Marko > > > Thanks Marco.. I discovered I'd forgotten to re-enable my -net subscription after my last trip DUH! Now for -current (cringes). julian From owner-freebsd-net@FreeBSD.ORG Thu Oct 27 01:46:07 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 2AA9F16A41F for ; Thu, 27 Oct 2005 01:46:07 +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 F11DD43D45 for ; Thu, 27 Oct 2005 01:46:06 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.117]) ([10.251.23.117]) by a50.ironport.com with ESMTP; 26 Oct 2005 18:46:04 -0700 X-IronPort-Anti-Spam-Filtered: true Message-ID: <4360315B.201@elischer.org> Date: Wed, 26 Oct 2005 18:46:03 -0700 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: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: -current link layer spaghetti diagram 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, 27 Oct 2005 01:46:07 -0000 A first attempt can be seen at: http://www.freebsd.org/~julian/layer2-current.pdf this is not a call graph, but a diagram of where packets can be passed. comments from vlan, pfil, CARP. if_bridge developers are welcome. those new-fangled bits worry me :-) julian From owner-freebsd-net@FreeBSD.ORG Thu Oct 27 02:16:24 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 E63E416A41F for ; Thu, 27 Oct 2005 02:16:24 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D64D43D45 for ; Thu, 27 Oct 2005 02:16:24 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 6EABB1CCDD; Thu, 27 Oct 2005 15:16:22 +1300 (NZDT) Date: Thu, 27 Oct 2005 15:16:22 +1300 From: Andrew Thompson To: Julian Elischer Message-ID: <20051027021622.GB81665@heff.fud.org.nz> References: <4360315B.201@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4360315B.201@elischer.org> User-Agent: Mutt/1.4.2.1i Cc: net@freebsd.org Subject: Re: -current link layer spaghetti diagram 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, 27 Oct 2005 02:16:25 -0000 On Wed, Oct 26, 2005 at 06:46:03PM -0700, Julian Elischer wrote: > A first attempt can be seen at: > http://www.freebsd.org/~julian/layer2-current.pdf > > this is not a call graph, but a diagram of where packets can be passed. > > comments from vlan, pfil, CARP. if_bridge developers are welcome. > those new-fangled bits worry me :-) > if_bridge looks fine. It does also hook into dummynet with a handoff/callback, but I dont know if you want that much detail. Andrew From owner-freebsd-net@FreeBSD.ORG Thu Oct 27 04:12:44 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 775A716A420; Thu, 27 Oct 2005 04:12:44 +0000 (GMT) (envelope-from julian@elischer.org) Received: from delight.idiom.com (outbound.idiom.com [216.240.47.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1394A43D6B; Thu, 27 Oct 2005 04:12:40 +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 5DEFC226B1B; Wed, 26 Oct 2005 21:12:39 -0700 (PDT) Received: from [192.168.2.6] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id j9R4CcYw071285; Wed, 26 Oct 2005 21:12:39 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <436053B6.1060302@elischer.org> Date: Wed, 26 Oct 2005 21:12:38 -0700 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: Andrew Thompson References: <4360315B.201@elischer.org> <20051027021622.GB81665@heff.fud.org.nz> In-Reply-To: <20051027021622.GB81665@heff.fud.org.nz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: -current link layer spaghetti diagram 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, 27 Oct 2005 04:12:44 -0000 Andrew Thompson wrote: >On Wed, Oct 26, 2005 at 06:46:03PM -0700, Julian Elischer wrote: > > >>A first attempt can be seen at: >>http://www.freebsd.org/~julian/layer2-current.pdf >> >>this is not a call graph, but a diagram of where packets can be passed. >> >>comments from vlan, pfil, CARP. if_bridge developers are welcome. >>those new-fangled bits worry me :-) >> >> >> > >if_bridge looks fine. It does also hook into dummynet with a >handoff/callback, but I dont know if you want that much detail. > > >Andrew > > I think I do want to show it if it is a possible packet path. I'll change it and add that path.. (and fix a bogon I just noticed.) check again in 20 minutes. I'm looking at what we can do to simplify this.. it's a mess.. Personally (I am biased of course) we could have imlemented almost everything outside of basic processing as netgraph modules. firewall, divert, bridging, vlans, CARP, flow control. these could have all been implemented as graph nodes.. well, too late for that. There are problems for example I'd rather that the if_bridge code didn't call the driver queue directly on output but passed it to the driver by calling ether_output_frame() and I'm not sure that the ipfw hook on output shouldn't be in ether_output() instead of in ether_output_frame(). I do think the output hook of netgraph should be above the bridging hook. If you are using netgraph you probably will use netgraph bridging as well but if you are using bridging that doesn't mean you don't want to do something with netgraph.. It's a bit of a problem actually. The order of calling these things almost wants to be adjustable because different people seem to want to call them in different orders. From owner-freebsd-net@FreeBSD.ORG Thu Oct 27 11:54: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 3E80616A420 for ; Thu, 27 Oct 2005 11:54:15 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: from web35702.mail.mud.yahoo.com (web35702.mail.mud.yahoo.com [66.163.179.156]) by mx1.FreeBSD.org (Postfix) with SMTP id 4AAB443D53 for ; Thu, 27 Oct 2005 11:54:14 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: (qmail 77473 invoked by uid 60001); 27 Oct 2005 11:54:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DMI7Dskm3sUn+4zufvNJpjCRhjiRP4YJx6YRxGvgyLedVGTn3ofrNr7z6WDLNnyqmigje2D2uTRPI8JHMGUIrjN9bVpU5QG9689aB8fdhU/EKXSD8yCPNWhTs8TvNc4HZGFlyrIHqtt5lMUEeCRxmav9VVBpgQy4DrvTot47VQQ= ; Message-ID: <20051027115411.77471.qmail@web35702.mail.mud.yahoo.com> Received: from [202.79.62.15] by web35702.mail.mud.yahoo.com via HTTP; Thu, 27 Oct 2005 04:54:10 PDT Date: Thu, 27 Oct 2005 04:54:10 -0700 (PDT) From: kamal kc To: freebsd MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd Subject: compiling the kernel faster 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, 27 Oct 2005 11:54:15 -0000 hello everybody, i am new to kernel programming. i am developing a compression/decompression functionality in the ip layer. i want to compile the kernel faster. it would be ok if the kernel doesn't have support for sound devices, or other devices like scsi,usb etc. because i would be using the compiled kernel for network data compression only. how could i do that. which source files and where in the makefiles do i make modifications ???? thanks for any suggestions kamal __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com From owner-freebsd-net@FreeBSD.ORG Thu Oct 27 12:14: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 CB8D416A41F; Thu, 27 Oct 2005 12:14:47 +0000 (GMT) (envelope-from ray@redshift.com) Received: from mail.quickmeet.com (quickmeet.com [216.228.17.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 960DE43D45; Thu, 27 Oct 2005 12:14:47 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (workstation [192.168.20.250]) by mail.quickmeet.com (Postfix) with SMTP id 5888117032; Thu, 27 Oct 2005 04:47:32 -0700 (PDT) Message-Id: <3.0.1.32.20051027051451.00a842c0@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Thu, 27 Oct 2005 05:14:51 -0700 To: kamal kc , freebsd From: ray@redshift.com In-Reply-To: <20051027115411.77471.qmail@web35702.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: freebsd Subject: Re: compiling the kernel faster 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, 27 Oct 2005 12:14:47 -0000 At 04:54 AM 10/27/2005 -0700, kamal kc wrote: | hello everybody, | | i am new to kernel programming. | i am developing a compression/decompression | functionality in the ip layer. | | i want to compile the kernel faster. | | it would | be ok if the kernel doesn't have support for sound | devices, or other devices like scsi,usb etc. because | i would be using the compiled kernel for | network data compression only. | | how could i do that. which source files and where in | the makefiles do i make modifications ???? | | thanks for any suggestions | | kamal Kamal, The files you modify to drop stuff out of the kernel are in /sys/i386/conf/ (assuming you are on an Intel platform). Copy the GENERIC file in there to something else (e.g DEVKERNEL), then edit that file. Comment out any drivers you don't need using # (check your dmesg output when you boot to see what drivers the OS is loading for your hardware). Don't comment out anything unless it's obviously something you don't need - doublt check the dmesg for stuff like network drivers, hard drive stuff, etc.) Once you comment out the drivers, you will need to re-compile the kernel. Go into /sys/i386/conf/ directory type this: config DEVKERNEL (using the example above) then change into the directory it shows you (should be something like ../compile/DEVKERNEL or something like that) and type this: make depend && make all install clean that will compile the new kernel and leave it in /boot/kernel (it will also backup your old kernel into kernel.old) go into /boot/kernel/ and type this: strip -s * then reboot using shutdown -r now If all goes well, you should boot to the new kernel. You can use the uname -a command to make sure you are on the new kernel okay. If the machine won't boot, you can boot into single user mode and copy the old kernel back in place. An excellent book on the subject is: Absolute BSD: The Ultimate Guide to FreeBSD (Paperback) good luck. Ray From owner-freebsd-net@FreeBSD.ORG Thu Oct 27 12:27: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 4704016A41F; Thu, 27 Oct 2005 12:27:03 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0A0043D46; Thu, 27 Oct 2005 12:27:02 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from 217-13-2-82.dd.nextgentel.com ([217.13.2.82] helo=marcin) by mail.yazzy.org with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1EV6pw-0001OL-NG; Thu, 27 Oct 2005 14:26:29 +0200 Date: Thu, 27 Oct 2005 14:27:06 +0200 From: Marcin Jessa To: kamal kc Message-Id: <20051027142706.26473f23.lists@yazzy.org> In-Reply-To: <20051027115411.77471.qmail@web35702.mail.mud.yahoo.com> References: <20051027115411.77471.qmail@web35702.mail.mud.yahoo.com> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.0 (GTK+ 2.6.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -2.5 (--) Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: compiling the kernel faster 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, 27 Oct 2005 12:27:03 -0000 On Thu, 27 Oct 2005 04:54:10 -0700 (PDT) kamal kc wrote: > hello everybody, > > i am new to kernel programming. > i am developing a compression/decompression > functionality in the ip layer. > > i want to compile the kernel faster. > > it would > be ok if the kernel doesn't have support for sound > devices, or other devices like scsi,usb etc. because > i would be using the compiled kernel for > network data compression only. > > how could i do that. which source files and where in > the makefiles do i make modifications ???? > > thanks for any suggestions Read the handbook - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig.html Next time remember to post to questions@ when asking begginer questions. Cheers Marcin From owner-freebsd-net@FreeBSD.ORG Thu Oct 27 23:36: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 71D1916A420 for ; Thu, 27 Oct 2005 23:36:22 +0000 (GMT) (envelope-from dmw@unete.cl) Received: from qmail2.ifxnetworks.com (qmail2.ifxnetworks.com [200.110.128.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 197BD43D49 for ; Thu, 27 Oct 2005 23:36:20 +0000 (GMT) (envelope-from dmw@unete.cl) Received: (qmail 32108 invoked from network); 27 Oct 2005 23:36:19 -0000 Received: from unknown (HELO hopto.org) ([200.73.29.233]) (envelope-sender ) by qmail2.ifxnetworks.com (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 27 Oct 2005 23:36:14 -0000 Received: from hopto.org (null@localhost.daemon.cl [127.0.0.1]) by hopto.org (8.13.4/8.13.1) with ESMTP id j9RNacGF039446; Thu, 27 Oct 2005 20:36:38 -0300 (CLST) (envelope-from dmw@unete.cl) Received: (from dmw@localhost) by hopto.org (8.13.4/8.13.1/Submit) id j9RNabjr039445; Thu, 27 Oct 2005 20:36:37 -0300 (CLST) (envelope-from dmw@unete.cl) X-Authentication-Warning: dmw.hopto.org: dmw set sender to dmw@unete.cl using -f Date: Thu, 27 Oct 2005 20:36:36 -0300 From: Daniel Molina Wegener To: ray@redshift.com Message-ID: <20051027233636.GA39380@dmw.hopto.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Description: message Content-Disposition: inline In-Reply-To: <3.0.1.32.20051027051451.00a842c0@pop.redshift.com> Organization: DMW Cc: kamal kc , freebsd , freebsd Subject: Re: compiling the kernel faster X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Molina Wegener List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2005 23:36:22 -0000 On Thu, Oct 27, 2005 at 05:14:51AM -0700, ray@redshift.com wrote: > At 04:54 AM 10/27/2005 -0700, kamal kc wrote: > | hello everybody, > | > | i am new to kernel programming. > | i am developing a compression/decompression > | functionality in the ip layer. > | > | i want to compile the kernel faster. > | > | it would > | be ok if the kernel doesn't have support for sound > | devices, or other devices like scsi,usb etc. because > | i would be using the compiled kernel for > | network data compression only. > | > | how could i do that. which source files and where in > | the makefiles do i make modifications ???? > | > | thanks for any suggestions > | > | kamal > > Kamal, > > The files you modify to drop stuff out of the kernel are in > /sys/i386/conf/ (assuming you are on an Intel platform). Copy > the GENERIC file in there to something else (e.g DEVKERNEL), > then edit that file. That's OK, also can take a look into the NOTES kernel config for additional options. > Comment out any drivers you don't need using # (check your > dmesg output when you boot to see what drivers the OS is > loading for your hardware). Don't comment out anything unless > it's obviously something you don't need - doublt check the > dmesg for stuff like network drivers, hard drive stuff, etc.) > > Once you comment out the drivers, you will need to re-compile > the kernel. Go into /sys/i386/conf/ directory type this: > > config DEVKERNEL (using the example above) > > then change into the directory it shows you (should be > something like ../compile/DEVKERNEL or something like that) > and type this: > > make depend && make all install clean > > that will compile the new kernel and leave it in /boot/kernel > (it will also backup your old kernel into kernel.old) Here are new instructions to compile the kernel. Go to the root source directory -- usually /usr/src -- then... make buildkernel KERNCONF=DEVKERNEL But, before making a new kernel, if you add new devices, edit the src/sys/conf/files to add the device properly. > go into /boot/kernel/ and type this: > > strip -s * > > then reboot using shutdown -r now Nope, if you are developing over the kernel _never_ strip the symbol table. Do not use the strip command. Instead, use the kernel config command flag in the DEVKERNEL config file. makeoptions DEBUG=-g This will enable symbol tables on the kernel for debugging purposes ;) > If all goes well, you should boot to the new kernel. You can > use the uname -a command to make sure you are on the new > kernel okay. If the machine won't boot, you can boot into > single user mode and copy the old kernel back in place. > > An excellent book on the subject is: > > Absolute BSD: The Ultimate Guide to FreeBSD (Paperback) > > good luck. > > Ray That's OK Also take a look on the FreeBSD Documetation Proyect. Regards. -- . 0 . | Daniel Molina Wegener . . 0 | dmw at unete dot cl 0 0 0 | FreeBSD Power User From owner-freebsd-net@FreeBSD.ORG Thu Oct 27 23:53: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 3F58C16A421; Thu, 27 Oct 2005 23:53:02 +0000 (GMT) (envelope-from vaibhave@cs.utah.edu) Received: from mail-svr1.cs.utah.edu (brahma.cs.utah.edu [155.98.64.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E1F843D5D; Thu, 27 Oct 2005 23:53:00 +0000 (GMT) (envelope-from vaibhave@cs.utah.edu) Received: from localhost (localhost [127.0.0.1]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id 998C1346EB; Thu, 27 Oct 2005 17:52:59 -0600 (MDT) Received: from mail-svr1.cs.utah.edu ([127.0.0.1]) by localhost (mail-svr1.cs.utah.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26618-05; Thu, 27 Oct 2005 17:52:59 -0600 (MDT) Received: from trust.cs.utah.edu (trust.cs.utah.edu [155.98.65.28]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id 4CF88346D3; Thu, 27 Oct 2005 17:52:59 -0600 (MDT) Received: by trust.cs.utah.edu (Postfix, from userid 4969) id 26DD63F6F; Thu, 27 Oct 2005 17:52:59 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by trust.cs.utah.edu (Postfix) with ESMTP id 189AC3F6C; Thu, 27 Oct 2005 17:52:59 -0600 (MDT) Date: Thu, 27 Oct 2005 17:52:59 -0600 (MDT) From: Vaibhave Agarwal To: freebsd In-Reply-To: <20051027233636.GA39380@dmw.hopto.org> Message-ID: References: <20051027233636.GA39380@dmw.hopto.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: amavisd-new at cs.utah.edu Cc: freebsd Subject: how to make the FreeBSD 6.0 run faster 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, 27 Oct 2005 23:53:02 -0000 In the file /usr/src/UPDATING, there is a following statement NOTE TO PEOPLE WHO THINK THAT FreeBSD 6.x IS SLOW: FreeBSD 6.x has many debugging features turned on, in both the kernel and userland. These features attempt to detect incorrect use of system primitives, and encourage loud failure through extra sanity checking and fail stop semantics. They also substantially impact system performance. If you want to do performance measurement, benchmarking, and optimization, you'll want to turn them off. This includes various WITNESS- related kernel options, INVARIANTS, malloc debugging flags in userland, and various verbose features in the kernel. Many developers choose to disable these features on build machines to maximize performance. How do u disable malloc debugging flags in the userland? I read somewhere that " ln -s aj /etc/malloc.conf" disables malloc debugging. How does it work? And how to disable verbose features in the kernel? Apart from this, are there other ways to make the kernel run faster?? thanks vaibhave From owner-freebsd-net@FreeBSD.ORG Fri Oct 28 01:30: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 431BB16A41F for ; Fri, 28 Oct 2005 01:30:00 +0000 (GMT) (envelope-from craig@olyun.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1306C43D49 for ; Fri, 28 Oct 2005 01:29:59 +0000 (GMT) (envelope-from craig@olyun.gank.org) Received: by ion.gank.org (mail, from userid 1001) id 872A12BDE7; Thu, 27 Oct 2005 20:29:59 -0500 (CDT) Date: Thu, 27 Oct 2005 20:29:57 -0500 From: Craig Boston To: freebsd-net@freebsd.org Message-ID: <20051028012957.GA50419@nowhere> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: 6.0-RC1 IPv6 losing local subnet route 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, 28 Oct 2005 01:30:00 -0000 [ I'm not subscribed to net@ so please copy me! ] It's been a while since I've used IPv6 (was on 4.x), so it's possible I'm doing something wrong, but it seems like this should work. Setup: A simple network with 3 or 4 FreeBSD boxes running 6.0-RC1. No contact with the outside world, no routers, just an ethernet switch. No rtadvd or rtsol -- everything is staticly configured. [SAMPLE] Box1: ifconfig em0 inet6 2002:abcd:ef01:5555::20/64 Box2: ifconfig em1 inet6 2002:abcd:ef01:5555::30/64 At first everything works like it should. However, after a seemingly random amount of time one of the machines loses its route for the local network. netstat -rn before it goes bad: Internet6: Destination Gateway Flags Netif ::1 ::1 UH lo0 2002:abcd:ef01:5555::/64 link#1 UC em0 2002:abcd:ef01:5555::20 00:07:e9:ab:cd:34 UHL lo0 2002:abcd:ef01:5555::30 00:07:e9:ab:cd:65 UHLW em0 and after: Internet6: Destination Gateway Flags Netif ::1 ::1 UH lo0 2002:abcd:ef01:5555::20 00:07:e9:ab:cd:34 UHL lo0 2002:abcd:ef01:5555::30 00:07:e9:ab:cd:65 UHLW em0 You can still ping6 any neighbors that have already been discovered, but any new ones just return "No route to host". Happens on every machine I've tested so far (but they were all running 6.0). Sometimes takes an hour or two, sometimes less. Bug or feature? Thanks, -- Craig From owner-freebsd-net@FreeBSD.ORG Fri Oct 28 03:56: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 2167816A41F for ; Fri, 28 Oct 2005 03:56:53 +0000 (GMT) (envelope-from suz@alaxala.net) Received: from mail4.hitachi.co.jp (mail4.hitachi.co.jp [133.145.228.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CF4843D46 for ; Fri, 28 Oct 2005 03:56:52 +0000 (GMT) (envelope-from suz@alaxala.net) Received: from mc2.mcg.hitachi.co.jp (unknown [133.144.237.46]) by mail4.hitachi.co.jp (Postfix) with ESMTP id 9587933CD3 for ; Fri, 28 Oct 2005 12:56:51 +0900 (JST) Received: (from root@localhost) by mc2.mcg.hitachi.co.jp (8.11.6+Sun/8.11.6) id j9S3uor15537 for freebsd-net@freebsd.org; Fri, 28 Oct 2005 12:56:50 +0900 (JST) Received: from unknown [192.168.2.1] by mc2.mcg.hitachi.co.jp with SMTP id NAA15534; Fri, 28 Oct 2005 12:56:50 +0900 Received: from mfilter-s1.hitachi.co.jp by mlsv3.hitachi.co.jp (8.12.10/8.12.10) id j9S3unWB018438; Fri, 28 Oct 2005 12:56:49 +0900 Received: from vshuts3.hitachi.co.jp (unverified) by mfilter-s1.hitachi.co.jp (Content Technologies SMTPRS 4.3.17) with SMTP id ; Fri, 28 Oct 2005 12:56:50 +0900 Received: from gmml16.itg.hitachi.co.jp ([158.213.165.46]) by vshuts3.hitachi.co.jp with SMTP id M2005102812564921938; Fri, 28 Oct 2005 12:56:49 +0900 Received: from flora220.uki-uki.net by gmml16.itg.hitachi.co.jp (AIX5.1/8.11.6p2/8.11.0) id j9S3unE498224; Fri, 28 Oct 2005 12:56:49 +0900 Date: Fri, 28 Oct 2005 12:55:49 +0900 Message-ID: From: SUZUKI Shinsuke To: craig@olyun.gank.org X-cite: xcite 1.33 In-Reply-To: <20051028012957.GA50419@nowhere> References: <20051028012957.GA50419@nowhere> User-Agent: Wanderlust/2.15.1 (Almost Unreal) Emacs/22.0 Mule/5.0 (SAKAKI) Organization: Technical Marketing Dept., ALAXALA Networks Corporation MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Cc: freebsd-net@freebsd.org Subject: Re: 6.0-RC1 IPv6 losing local subnet route 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, 28 Oct 2005 03:56:53 -0000 Hello Craig, >>>>> On Thu, 27 Oct 2005 20:29:57 -0500 >>>>> craig@olyun.gank.org(Craig Boston) said: > [ I'm not subscribed to net@ so please copy me! ] > It's been a while since I've used IPv6 (was on 4.x), so it's possible > I'm doing something wrong, but it seems like this should work. (snip) > [SAMPLE] > Box1: > ifconfig em0 inet6 2002:abcd:ef01:5555::20/64 > Box2: > ifconfig em1 inet6 2002:abcd:ef01:5555::30/64 Let me confirm. In your configuration, em0 and em1 have the same prefix. Is it intentionally configured? #normally, IPv6 operator does not assign prefix in such manner... Thanks, ---- SUZUKI, Shinsuke @ KAME Project From owner-freebsd-net@FreeBSD.ORG Fri Oct 28 04:09: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 49E3E16A427 for ; Fri, 28 Oct 2005 04:09:03 +0000 (GMT) (envelope-from craig@olyun.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0891B43D5C for ; Fri, 28 Oct 2005 04:09:01 +0000 (GMT) (envelope-from craig@olyun.gank.org) Received: by ion.gank.org (mail, from userid 1001) id B37AF2BC50; Thu, 27 Oct 2005 23:09:01 -0500 (CDT) Date: Thu, 27 Oct 2005 23:09:01 -0500 From: Craig Boston To: SUZUKI Shinsuke Message-ID: <20051028040901.GA47012@nowhere> References: <20051028012957.GA50419@nowhere> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: 6.0-RC1 IPv6 losing local subnet route 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, 28 Oct 2005 04:09:04 -0000 On Fri, Oct 28, 2005 at 12:55:49PM +0900, SUZUKI Shinsuke wrote: > Let me confirm. > > In your configuration, em0 and em1 have the same prefix. > Is it intentionally configured? > #normally, IPv6 operator does not assign prefix in such manner... Yes, but em0 and em1 are on different computers attached to the same network (em0 on the second computer isn't connected to anything right now). I think they have to have the same prefix to talk to each other without routing? Craig From owner-freebsd-net@FreeBSD.ORG Fri Oct 28 06:18:50 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 28D7916A420; Fri, 28 Oct 2005 06:18:50 +0000 (GMT) (envelope-from saundersconsult@hotmail.com) Received: from hotmail.com (bay101-dav3.bay101.hotmail.com [64.4.56.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id A743143D46; Fri, 28 Oct 2005 06:18:49 +0000 (GMT) (envelope-from saundersconsult@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 27 Oct 2005 23:18:49 -0700 Message-ID: Received: from 24.205.176.247 by BAY101-DAV3.phx.gbl with DAV; Fri, 28 Oct 2005 06:18:49 +0000 X-Originating-IP: [24.205.176.247] X-Originating-Email: [saundersconsult@hotmail.com] X-Sender: saundersconsult@hotmail.com From: "Shawn Saunders" To: "Gleb Smirnoff" References: <20051021053228.GX59364@cell.sick.ru> <20051026141733.GI41520@cell.sick.ru> Date: Thu, 27 Oct 2005 23:18:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-OriginalArrivalTime: 28 Oct 2005 06:18:49.0706 (UTC) FILETIME=[760564A0:01C5DB87] Cc: dionch@freemail.gr, freebsd-net@FreeBSD.org Subject: Re: Trying to make a Host into a gigabit hub for testing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Shawn Saunders List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2005 06:18:50 -0000 I'll test it, but that is what I am seeing now. Shawn ----- Original Message ----- From: "Gleb Smirnoff" To: "Shawn Saunders" Cc: ; Sent: Wednesday, October 26, 2005 7:17 AM Subject: Re: Trying to make a Host into a gigabit hub for testing > On Wed, Oct 26, 2005 at 07:15:18AM -0700, Shawn Saunders wrote: > S> Actually, I think one2many is more appropriate. I do not want the > traffic > S> that is coming in on the incoming ports to be echoed back to them, and > S> isn't that what the ng_hub would do? > > No, it wouldn't. It will send to all ports except of the port the > packet was received on. > > P.S. Please do not top quote. > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > From owner-freebsd-net@FreeBSD.ORG Fri Oct 28 07:19: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 B00C616A41F for ; Fri, 28 Oct 2005 07:19:36 +0000 (GMT) (envelope-from suz@alaxala.net) Received: from mail4.hitachi.co.jp (mail4.hitachi.co.jp [133.145.228.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 329F243D45 for ; Fri, 28 Oct 2005 07:19:35 +0000 (GMT) (envelope-from suz@alaxala.net) Received: from mc4.mcg.hitachi.co.jp (unknown [133.144.237.44]) by mail4.hitachi.co.jp (Postfix) with ESMTP id 3852F33CD3 for ; Fri, 28 Oct 2005 16:19:35 +0900 (JST) Received: (from root@localhost) by mc4.mcg.hitachi.co.jp (8.11.6+Sun/8.11.6) id j9S7JYn29363 for freebsd-net@freebsd.org; Fri, 28 Oct 2005 16:19:34 +0900 (JST) Received: from unknown [192.168.2.1] by mc4.mcg.hitachi.co.jp with SMTP id SAA29360; Fri, 28 Oct 2005 16:19:34 +0900 Received: from mfilter-s3.hitachi.co.jp by mlsv8.hitachi.co.jp (8.12.11/8.12.11) id j9S7JXUp028377; Fri, 28 Oct 2005 16:19:33 +0900 Received: from vshuts2.hitachi.co.jp (unverified) by mfilter-s3.hitachi.co.jp (Content Technologies SMTPRS 4.3.17) with SMTP id ; Fri, 28 Oct 2005 16:19:33 +0900 Received: from gmml16.itg.hitachi.co.jp ([158.213.165.46]) by vshuts2.hitachi.co.jp with SMTP id M2005102816193308531; Fri, 28 Oct 2005 16:19:33 +0900 Received: from flora220.uki-uki.net by gmml16.itg.hitachi.co.jp (AIX5.1/8.11.6p2/8.11.0) id j9S7JXE112520; Fri, 28 Oct 2005 16:19:33 +0900 Date: Fri, 28 Oct 2005 16:18:33 +0900 Message-ID: From: SUZUKI Shinsuke To: craig@olyun.gank.org X-cite: xcite 1.33 In-Reply-To: <20051028040901.GA47012@nowhere> References: <20051028012957.GA50419@nowhere> <20051028040901.GA47012@nowhere> User-Agent: Wanderlust/2.15.1 (Almost Unreal) Emacs/22.0 Mule/5.0 (SAKAKI) Organization: Technical Marketing Dept., ALAXALA Networks Corporation MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Cc: freebsd-net@freebsd.org Subject: Re: 6.0-RC1 IPv6 losing local subnet route 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, 28 Oct 2005 07:19:36 -0000 >>>>> On Thu, 27 Oct 2005 23:09:01 -0500 >>>>> craig@olyun.gank.org(Craig Boston) said: > > In your configuration, em0 and em1 have the same prefix. > > Is it intentionally configured? > > #normally, IPv6 operator does not assign prefix in such manner... > > Yes, but em0 and em1 are on different computers attached to the same > network (em0 on the second computer isn't connected to anything right > now). I think they have to have the same prefix to talk to each other > without routing? Now I understand the situation. (I thought em0 and em1 belong to the same box) I'll check it on this weekend. From owner-freebsd-net@FreeBSD.ORG Fri Oct 28 10:24: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 1DC3516A420; Fri, 28 Oct 2005 10:24:19 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id B83AA43D45; Fri, 28 Oct 2005 10:24:18 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 414F746BB1; Fri, 28 Oct 2005 06:24:18 -0400 (EDT) Date: Fri, 28 Oct 2005 11:24:18 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Vaibhave Agarwal In-Reply-To: Message-ID: <20051028105057.J20147@fledge.watson.org> References: <20051027233636.GA39380@dmw.hopto.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd , freebsd Subject: Re: how to make the FreeBSD 6.0 run faster 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, 28 Oct 2005 10:24:19 -0000 On Thu, 27 Oct 2005, Vaibhave Agarwal wrote: > How do u disable malloc debugging flags in the userland? I read > somewhere that " ln -s aj /etc/malloc.conf" disables malloc debugging. > How does it work? > > And how to disable verbose features in the kernel? > > Apart from this, are there other ways to make the kernel run faster?? The note has now been removed, since it was accurate only through the beta series. "Run faster" is a bit nebulous, as performance optimization is a complex thing. Since you CC'd the net@ list, I assume you want the networking to run faster. The usual techniques are: - If your workload permits it, run with network stack direct dispatch, which avoids a context switch into the network stack. Be warned that this may reduce the opportunities for parallelism between the interrupt and link layer code and network layer code, so while it improves many workloads, it won't improve all. Set net.dispatch.direct=1. - If your workload benefits from it, consider running with device polling -- this moves form an interrupt driven network model to a polled network model, greatly decreasing overhead as a result of avoiding thrashing interrupt handlers, and allowing you to moderate the load generated by the network. See polling(4) for details, as this requires a custom kernel configuration and some careful thought. This is usually best for routers, etc. Polling may increase the latency of packet processing based on how frequently polling polls, but substantially increase throughput. - Depending on the workload and hardware, you may want to reconsider compiling with SMP. I.e., for some workloads, HTT helps, and SMP helps, and for other workloads, it doesn't. - Carefully evaluate your hardware configuration -- if this is about network performance, you may want to make sure that storage and networking devices are on separate PCI buses, and that if needed, those buses are 64-bit. - Another common hardware issue is shared interrupts -- for example, on many motherboards, USB and the on-motherboard network device end up on the same interrupt, or their interrupts fire simultaneously regardless of the interrupt numbers. Since the USB code is pretty heavy-weight, you don't want to run it every time you receive a batch of packets via an interrupt for gig-e. Compiling out USB in this environment may help. This problem can be detected using vmstat -i, and seeing if the interrupt rates for USB and your motherboard network device both look the same -- i.e., very big. - Another common concern with threaded network applications is whether the thread library model and implementation match the requirements of your application. FreeBSD provides several thread libraries with different properties, so you might want to consider changing thread libraries. - Recent reports indicate that on some systems, slow time counters are used during context switches. You may want to consider switching to a faster time counter if time accuracy is less important to you. In one measurement, this added 30% performance to loop-back network traffic. This issue is being actively researched. Other than that, you'll need to tell us what you're doing. Robert N M Watson From owner-freebsd-net@FreeBSD.ORG Fri Oct 28 10:34: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 749F216A420 for ; Fri, 28 Oct 2005 10:34:56 +0000 (GMT) (envelope-from daniel@dgnetwork.com.br) Received: from zeus.yan.com.br (zeus.yan.com.br [200.202.253.10]) by mx1.FreeBSD.org (Postfix) with SMTP id EC0CE43D45 for ; Fri, 28 Oct 2005 10:34:54 +0000 (GMT) (envelope-from daniel@dgnetwork.com.br) Received: (qmail 5516 invoked by uid 1023); 28 Oct 2005 10:34:27 -0000 Received: from daniel@dgnetwork.com.br by zeus by uid 1023 with qmail-scanner-1.22 (uvscan: v4.1.60/v4366. fsecure: 4.11/3190/2003-09-23/2002-12-17. 2003-09-22/. Clear:RC:1(201.19.84.78):. Processed in 0.655562 secs); 28 Oct 2005 10:34:27 -0000 Received: from unknown (HELO ?192.168.1.2?) (daniel@dgnetwork.com.br@201.19.84.78) by zeus.yan.com.br with SMTP; 28 Oct 2005 10:34:26 -0000 Message-ID: <4361FE7E.50607@dgnetwork.com.br> Date: Fri, 28 Oct 2005 08:33:34 -0200 From: =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?= Organization: DGNET Network Solutions User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: pt-br, pt MIME-Version: 1.0 To: freebsd-pf@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Load Balancing Outgoing, its possible ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: daniel@dgnetwork.com.br List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2005 10:34:56 -0000 Complicated ? Its possible ? TELECOM LOAD SHARING PER PACKET ------------------------------------------------------------------------------------------ | | | | | | | | | | | | ------------------------------------- ------------------------------------- CISCO 2600 (6mbps) HAUWEI (6mbps) LOAD SHARING PER PACKET LOAD SHARING PER PACKET ------------------------------------- ------------------------------------- Ethernet (64.XX.XX.1/30) Ethernet (65.XX.XX.1/30) | | | | | | XL0 (64.XX.XX.2/30) XL1 (65.XX.XX.2/30) ------------------------------------------------------------------------------------------ FREEBSD 5.4 + PF ------------------------------------------------------------------------------------------ XL2 (192.168.0.254/24, 64.XX.XX.5/30, 65.XX.XX.5/30) | | ------------------ SWITCH ------------------------------- IP: 65.XX.XX.6/30 ------------------ GW: 65.XX.XX.5 / \ / \ IP: 192.168.0.10/24 IP: 64.XX.XX.6/30 GW: 192.168.0.254 GW: 64.XX.XX.5 and more clients ... I need load balancing outgoing traffic from: 192.168.0.0/24 ( NAT ) and 64.XX.XX.0/24, 65.XX.XX.0/24 It is possible to make this balancing with the PF ? Exists some software that I make this ? Zebra can help me? This type of balancing gives to problems with the navigation of the user of NAT or IP valid ? If it is possible, wanted to see examples with rules. Thanks, -- Daniel Dias Gonçalves DGNET Network Solutions daniel@dgnetwork.com.br (37) 99824809 From owner-freebsd-net@FreeBSD.ORG Fri Oct 28 11:06: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 5EE7616A441 for ; Fri, 28 Oct 2005 11:06:52 +0000 (GMT) (envelope-from nuno.antunes@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0A0C43D46 for ; Fri, 28 Oct 2005 11:06:51 +0000 (GMT) (envelope-from nuno.antunes@gmail.com) Received: by zproxy.gmail.com with SMTP id 40so396462nzk for ; Fri, 28 Oct 2005 04:06:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GAxIxumqzLnsC2u8slLJG4ion2mWyz2A9F+k7cTiYtKZwWVhCKMx0KukicrT4AJndqbE88hCGCbUWWv/lca95LJ0Udjc7HnnyL33UbUlMcJsMRs8qnvUIQkwBhr+eken8qUbeUx9XJDjMU/SQD9SfIinE/tiGL++keIsSUy/GQ4= Received: by 10.36.109.13 with SMTP id h13mr149251nzc; Fri, 28 Oct 2005 04:06:51 -0700 (PDT) Received: by 10.36.113.15 with HTTP; Fri, 28 Oct 2005 04:06:51 -0700 (PDT) Message-ID: <262949390510280406w66190f85va1ef1a6450f13019@mail.gmail.com> Date: Fri, 28 Oct 2005 12:06:51 +0100 From: Nuno Antunes To: freebsd-net@freebsd.org In-Reply-To: <436004BE.4020600@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <435FEB14.4080007@elischer.org> <43600089.4050909@elischer.org> <200510270030.12947.zec@icir.org> <436004BE.4020600@elischer.org> Subject: Re: diagram of 4.10 layer 2 spaghetti 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, 28 Oct 2005 11:06:52 -0000 On 10/26/05, Julian Elischer wrote: > at: > > http://people.freebsd.org/~julian/layer2b.pdf > > I'm going to do one for RELENG_4 by add in the bits added, > and then, the big task.. > > one for -current Very nice diagram, thanks! Now all I need is a good mbuf tutorial ;-) Best regards, Nuno Antunes From owner-freebsd-net@FreeBSD.ORG Fri Oct 28 12:01: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 0B15616A41F; Fri, 28 Oct 2005 12:01:42 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms042pub.verizon.net (vms042pub.verizon.net [206.46.252.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4B7643D53; Fri, 28 Oct 2005 12:01:41 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms062.mailsrvcs.net ([192.168.1.3]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0IP200I05K2T8C20@vms042.mailsrvcs.net>; Fri, 28 Oct 2005 07:01:41 -0500 (CDT) Date: Fri, 28 Oct 2005 07:01:41 -0500 (CDT) From: Sergey Babkin To: Vaibhave Agarwal Message-id: <20858923.1130500901324.JavaMail.root@vms062.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: freebsd , freebsd Subject: Re: Re: how to make the FreeBSD 6.0 run faster X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: babkin@users.sf.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2005 12:01:42 -0000 >From: Robert Watson >On Thu, 27 Oct 2005, Vaibhave Agarwal wrote: > >> How do u disable malloc debugging flags in the userland? I read >> somewhere that " ln -s aj /etc/malloc.conf" disables malloc debugging. >> How does it work? >> >> And how to disable verbose features in the kernel? >> >> Apart from this, are there other ways to make the kernel run faster?? > >Other than that, you'll need to tell us what you're doing. And the most important part: try to optimize your application first. I've seen a surprizing number of people who feel that they need to do something with the kernel while what is really suboptimal (or downright broken) is their application. When writing programs people make many assumptions about what is fast and often these assumptions are wrong, plus there are bugs where the code generally works but does it slowly. This is especially true for applications written in C++ and other OO languages, and for threaded applications. If you want to have a cost-efficient solution, the applications really need to be profiled and measured, and all the performance squeezed out of them before going into the kernel. -SB From owner-freebsd-net@FreeBSD.ORG Fri Oct 28 13:35: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 8540416A41F; Fri, 28 Oct 2005 13:35:19 +0000 (GMT) (envelope-from ray@redshift.com) Received: from mail.quickmeet.com (quickmeet.com [216.228.17.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id A932E43D45; Fri, 28 Oct 2005 13:35:17 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (workstation [192.168.20.250]) by mail.quickmeet.com (Postfix) with SMTP id 7294617032; Fri, 28 Oct 2005 06:07:51 -0700 (PDT) Message-Id: <3.0.1.32.20051028063522.00a75268@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Fri, 28 Oct 2005 06:35:22 -0700 To: babkin@users.sf.net, Vaibhave Agarwal From: ray@redshift.com In-Reply-To: <20858923.1130500901324.JavaMail.root@vms062.mailsrvcs.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: freebsd , freebsd Subject: Re: Re: how to make the FreeBSD 6.0 run faster 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, 28 Oct 2005 13:35:19 -0000 At 07:01 AM 10/28/2005 -0500, Sergey Babkin wrote: | >From: Robert Watson | >On Thu, 27 Oct 2005, Vaibhave Agarwal wrote: | > | >> How do u disable malloc debugging flags in the userland? I read | >> somewhere that " ln -s aj /etc/malloc.conf" disables malloc debugging. | >> How does it work? | >> | >> And how to disable verbose features in the kernel? | >> | >> Apart from this, are there other ways to make the kernel run faster?? | > | >Other than that, you'll need to tell us what you're doing. | | And the most important part: try to optimize your application | first. I've seen a surprizing number of people who feel | that they need to do something with the kernel while what | is really suboptimal (or downright broken) is their application. | When writing programs people make many assumptions about | what is fast and often these assumptions are wrong, plus | there are bugs where the code generally works but does it slowly. | This is especially true for applications written in C++ | and other OO languages, and for threaded applications. | If you want to have a cost-efficient solution, the applications | really need to be profiled and measured, and all the performance | squeezed out of them before going into the kernel. | | -SB | I will second that. In some recent benchmarks I did with our web application, I discovered that I was able to get a nearly 200% boost in speed (i.e. things ran twice as fast) by simply changing how I was handling variables in PHP. The golden rule of performance tweaking is *assume nothing, test everything*. I have read papers on PHP for example that swear up and down that removing comments will not improve speed and that it's just a myth. BS, removing comments does improve speed because the interpreter has less to sift through. Usually performance tuning is the combination of many small improvements, not any one major short fall. Without knowing your exact application, I can't say specifically, but in most all of my cases, the Kernel itself (even when fully optimized) only added about 20 or 30% to any given situation. In my experience, what makes a server scream is the combination of many small performance increases including everything from faster hard drive, more streamlined kernel, streamlined apps, better compilation, better coding on your application, better threading, etc, etc. Eventually you'll reach a point where the time needed to produce further gains becomes a diminishing returns situation and/or stability would have to be sacrificed. At that point, generally it's better, cheaper and faster to just add additional hardware (assuming you are working in a cluster). But to echo what Sergey says, you'd be surprised how often poor coding is the root of the problem, not the kernel. Ray From owner-freebsd-net@FreeBSD.ORG Fri Oct 28 14:15: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 894EF16A41F for ; Fri, 28 Oct 2005 14:15:40 +0000 (GMT) (envelope-from mocart@pinco.pl) Received: from pinco.pl (gw-z-futuro.pinco.pl [62.233.197.58]) by mx1.FreeBSD.org (Postfix) with SMTP id 0CEF743D48 for ; Fri, 28 Oct 2005 14:15:38 +0000 (GMT) (envelope-from mocart@pinco.pl) Received: (qmail 51952 invoked by uid 1001); 28 Oct 2005 14:18:06 -0000 Date: Fri, 28 Oct 2005 16:18:06 +0200 From: =?utf-8?Q?=C5=81ukasz?= Dudek To: Daniel Dias =?iso-8859-1?Q?Gon=E7alves?= Message-ID: <20051028141806.GA51784@pinco.pl> References: <4361FE7E.50607@dgnetwork.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4361FE7E.50607@dgnetwork.com.br> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Subject: Re: Load Balancing Outgoing, its possible ? 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, 28 Oct 2005 14:15:40 -0000 Dnia Fri, Oct 28, 2005 at 08:33:34AM -0200, Daniel Dias Gonçalves napisaÅ‚(a): > > It is possible to make this balancing with the PF ? Exists some software > that I make this ? Zebra can help me? > This type of balancing gives to problems with the navigation of the user > of NAT or IP valid ? > If it is possible, wanted to see examples with rules. > it is possible. #BALANCING TWO INTERNET CONNECTIONS # #People who have multiple net connections and are unable to use a proper #multipath routing solution (ie. BGP4) can use this to balance *outgoing* #traffic across the two connections, with something like this: # # nat on $ext_if1 from $int_subnet to any -> ($ext_if1) nat on $ext_if2 from $int_subnet to any -> ($ext_if2) # ## routing for internal subnets pass in on $int_if \ # route-to { ( $ext_if1 $gateway1), ( $ext_if2 $gateway2 ) } round-robin \ # from $int_subnet to any keep state # ## need the next rules to properly pass traffic to/from the external IPs pass out on $ext_if2 route-to ($ext_if1 $gateway1) from $ext_if1 to any pass out on $ext_if1 route-to ($ext_if2 $gateway2) from $ext_if2 to any # # #Please note that this is only the skeleton of a ruleset that would work #in such a situation; care must be taken to ensure that the correct route-to options are put on each rule which needs to be balanced pozdr mocart From owner-freebsd-net@FreeBSD.ORG Fri Oct 28 15:06: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 E0DFD16A426 for ; Fri, 28 Oct 2005 15:06:07 +0000 (GMT) (envelope-from suz@alaxala.net) Received: from pc1.alaxala.kame.net (kame219.kame.net [203.178.141.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7659743D45 for ; Fri, 28 Oct 2005 15:06:06 +0000 (GMT) (envelope-from suz@alaxala.net) Received: from localhost (localhost [127.0.0.1]) by pc1.alaxala.kame.net (Postfix) with ESMTP id 89DAE625C; Sat, 29 Oct 2005 00:07:13 +0900 (JST) Received: from pc1.alaxala.kame.net ([127.0.0.1]) by localhost (pc1.alaxala.kame.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34108-03; Sat, 29 Oct 2005 00:07:08 +0900 (JST) Received: from flora220.uki-uki.net (240.163.192.61.tokyo.global.alpha-net.ne.jp [61.192.163.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pc1.alaxala.kame.net (Postfix) with ESMTP id 65C1461C9; Sat, 29 Oct 2005 00:07:07 +0900 (JST) Date: Sat, 29 Oct 2005 00:04:53 +0900 Message-ID: From: SUZUKI Shinsuke To: craig@olyun.gank.org X-cite: xcite 1.33 In-Reply-To: References: <20051028012957.GA50419@nowhere> <20051028040901.GA47012@nowhere> User-Agent: Wanderlust/2.15.1 (Almost Unreal) Emacs/22.0 Mule/5.0 (SAKAKI) Organization: Technical Marketing Dept., ALAXALA Networks Corporation MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: amavisd-new at alaxala.kame.net Cc: freebsd-net@freebsd.org Subject: Re: 6.0-RC1 IPv6 losing local subnet route 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, 28 Oct 2005 15:06:08 -0000 Hello Craig, >>>>> On Fri, 28 Oct 2005 16:18:33 +0900 >>>>> suz@kame.net(SUZUKI Shinsuke) said: > > Yes, but em0 and em1 are on different computers attached to the same > > network (em0 on the second computer isn't connected to anything right > > now). I think they have to have the same prefix to talk to each other > > without routing? > Now I understand the situation. (I thought em0 and em1 belong to the > same box) > > I'll check it on this weekend. I tried the same test using my PC with fxp drivers, but your phenomena did not happen in my environment (at least for five hours). Maybe the configured prefix was regarded as off-link by some reason. (it is theoretically possible in IPv6, but I'm not sure whether it really happens in your case) To confirm this, could you show me the result of the following commands before and after the trouble? - ndp -p - ifconfig -a Thanks, ---- SUZUKI, Shinsuke @ KAME Project From owner-freebsd-net@FreeBSD.ORG Fri Oct 28 15:21: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 4A4CF16A41F; Fri, 28 Oct 2005 15:21:16 +0000 (GMT) (envelope-from gbryant@roamingsolutions.net) Received: from basillia.speedxs.net (basillia.speedxs.net [83.98.255.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id A88B143D48; Fri, 28 Oct 2005 15:21:15 +0000 (GMT) (envelope-from gbryant@roamingsolutions.net) Received: from ongers.net (ongers.speedxs.nl [83.98.237.210]) by basillia.speedxs.net (Postfix) with ESMTP id 3115B6013; Fri, 28 Oct 2005 17:07:56 +0200 (CEST) Received: from (165.146.215.66 [165.146.215.66]) by MailEnable Inbound Mail Agent with ESMTP; Fri, 28 Oct 2005 17:26:55 +0200 Message-ID: <43624181.5010305@roamingsolutions.net> Date: Fri, 28 Oct 2005 17:19:29 +0200 From: G Bryant User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: daniel@dgnetwork.com.br References: <4361FE7E.50607@dgnetwork.com.br> In-Reply-To: <4361FE7E.50607@dgnetwork.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 0543-2, 2005/10/27), Outbound message X-Antivirus-Status: Clean Cc: freebsd-net@freebsd.org, FreeBSD , freebsd-pf@freebsd.org Subject: Re: Load Balancing Outgoing, its possible ? 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, 28 Oct 2005 15:21:16 -0000 Daniel Dias Gonçalves wrote: > > Complicated ? Its possible ? > > TELECOM > LOAD SHARING PER PACKET > ------------------------------------------------------------------------------------------ > > | | | | > | | > | | | | > | | > ------------------------------------- > ------------------------------------- > CISCO 2600 (6mbps) HAUWEI (6mbps) > LOAD SHARING PER PACKET LOAD SHARING PER > PACKET > ------------------------------------- > ------------------------------------- > Ethernet (64.XX.XX.1/30) Ethernet > (65.XX.XX.1/30) > | | > | | > | | > XL0 (64.XX.XX.2/30) XL1 > (65.XX.XX.2/30) > ------------------------------------------------------------------------------------------ > > FREEBSD 5.4 + PF > ------------------------------------------------------------------------------------------ > > XL2 (192.168.0.254/24, 64.XX.XX.5/30, 65.XX.XX.5/30) > | > | > ------------------ > SWITCH > ------------------------------- IP: 65.XX.XX.6/30 > > ------------------ GW: > 65.XX.XX.5 > / \ > / \ > IP: 192.168.0.10/24 IP: 64.XX.XX.6/30 > GW: 192.168.0.254 GW: 64.XX.XX.5 > and more clients ... > I need load balancing outgoing traffic from: > 192.168.0.0/24 ( NAT ) > and 64.XX.XX.0/24, 65.XX.XX.0/24 > > It is possible to make this balancing with the PF ? Exists some > software that I make this ? Zebra can help me? > This type of balancing gives to problems with the navigation of the > user of NAT or IP valid ? > If it is possible, wanted to see examples with rules. > > Thanks, > If you do not manage to come right with PF, I have a working example of a similar setup using IPFW & natd. Let me know if you would like the config files. Regards Graham From owner-freebsd-net@FreeBSD.ORG Fri Oct 28 15:25: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 8845316A41F; Fri, 28 Oct 2005 15:25:42 +0000 (GMT) (envelope-from vd@datamax.bg) Received: from jengal.datamax.bg (jengal.datamax.bg [82.103.104.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F57943D53; Fri, 28 Oct 2005 15:25:41 +0000 (GMT) (envelope-from vd@datamax.bg) Received: from qlovarnika.bg.datamax (qlovarnika.bg.datamax [192.168.10.2]) by jengal.datamax.bg (Postfix) with SMTP id 0A153B854; Fri, 28 Oct 2005 18:25:40 +0300 (EEST) Received: (nullmailer pid 43051 invoked by uid 1002); Fri, 28 Oct 2005 15:25:39 -0000 Date: Fri, 28 Oct 2005 18:25:39 +0300 From: Vasil Dimov To: Vaibhave Agarwal Message-ID: <20051028152539.GA42957@qlovarnika.bg.datamax> References: <20051027233636.GA39380@dmw.hopto.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 6.0-RC1 User-Agent: Mutt/1.5.11 Cc: freebsd , freebsd Subject: Re: how to make the FreeBSD 6.0 run faster X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vd@datamax.bg List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2005 15:25:42 -0000 I would just like to add some numbers: system: freebsd 6.0 i386 job: make buildworld buildkernel When kernel and world are compiled with -g and witness,memguard,invariants are switched on the job takes 120min. With witness,memguard,invariants turned off it takes 66min. 1/3 More speedup when using world and kernel, compiled with -O2 instead of -g, and yet 10% more speedup when removing J option from malloc.conf(3). -- Vasil Dimov From owner-freebsd-net@FreeBSD.ORG Fri Oct 28 15:44: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 37F9516A41F; Fri, 28 Oct 2005 15:44:42 +0000 (GMT) (envelope-from csmith@bonddesk.com) Received: from msmisps01.bonddesk.com (msmisps01.bonddesk.com [12.47.70.99]) by mx1.FreeBSD.org (Postfix) with ESMTP id 687B143D70; Fri, 28 Oct 2005 15:44:30 +0000 (GMT) (envelope-from csmith@bonddesk.com) Received: from mimail.bdg.local ([10.132.16.100]) by chmail.bdg.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 11:44:29 -0400 Received: from 10.133.16.35 ([10.133.16.35]) by mimail.bdg.local ([10.132.16.100]) with Microsoft Exchange Server HTTP-DAV ; Fri, 28 Oct 2005 15:44:28 +0000 Received: from csmith-dt.bdg.local by mimail.bonddesk.com; 28 Oct 2005 11:44:28 -0400 From: Corey Smith To: G Bryant In-Reply-To: <43624181.5010305@roamingsolutions.net> References: <4361FE7E.50607@dgnetwork.com.br> <43624181.5010305@roamingsolutions.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Oct 2005 11:44:27 -0400 Message-Id: <1130514267.81705.101.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port X-OriginalArrivalTime: 28 Oct 2005 15:44:29.0011 (UTC) FILETIME=[7B6C5A30:01C5DBD6] Cc: daniel@dgnetwork.com.br, freebsd-net@freebsd.org, freebsd-pf@freebsd.org, FreeBSD Subject: Re: Load Balancing Outgoing, its possible ? 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, 28 Oct 2005 15:44:42 -0000 On Fri, 2005-10-28 at 17:19 +0200, G Bryant wrote: > Daniel Dias Gon=E7alves wrote: >=20 > > > > It is possible to make this balancing with the PF ? Exists some=20 > > software that I make this ? Zebra can help me? > > This type of balancing gives to problems with the navigation of the=20 > > user of NAT or IP valid ? > > If it is possible, wanted to see examples with rules. > > It would be much better to do per flow load balancing then per packet. With per packet your TCP flows will arrive out of order which is a bad situation since it will lead to a large number of retransmissions and zero-window acknowledgments. The only tunable to help correct that is to allow selective acknowledgments. You are going to get much higher utilization on your load balanced lines by using per flow with multiple TCP connections. Anybody know how to implement per flow load balancing in FreeBSD? Are multiple default routes supported? It would be beautiful if you could put multiple routes with the same metric into the kernel and then the kernel would enable per flow load balancing of the routes... -Corey Smith From owner-freebsd-net@FreeBSD.ORG Fri Oct 28 16:03: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 C02AC16A41F for ; Fri, 28 Oct 2005 16:03:34 +0000 (GMT) (envelope-from daniel@dgnetwork.com.br) Received: from zeus.yan.com.br (zeus.yan.com.br [200.202.253.10]) by mx1.FreeBSD.org (Postfix) with SMTP id DA4CA43D49 for ; Fri, 28 Oct 2005 16:03:32 +0000 (GMT) (envelope-from daniel@dgnetwork.com.br) Received: (qmail 3671 invoked by uid 1023); 28 Oct 2005 16:03:04 -0000 Received: from daniel@dgnetwork.com.br by zeus by uid 1023 with qmail-scanner-1.22 (uvscan: v4.1.60/v4366. fsecure: 4.11/3190/2003-09-23/2002-12-17. 2003-09-22/. Clear:RC:1(201.19.130.165):. Processed in 0.570881 secs); 28 Oct 2005 16:03:04 -0000 Received: from unknown (HELO ?192.168.1.2?) (daniel@dgnetwork.com.br@201.19.130.165) by zeus.yan.com.br with SMTP; 28 Oct 2005 16:03:03 -0000 Message-ID: <43624BCE.6010907@dgnetwork.com.br> Date: Fri, 28 Oct 2005 14:03:26 -0200 From: =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?= Organization: DGNET Network Solutions User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: pt-br, pt MIME-Version: 1.0 To: Corey Smith , freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org, freebsd-pf@freebsd.org References: <4361FE7E.50607@dgnetwork.com.br> <43624181.5010305@roamingsolutions.net> <1130514267.81705.101.camel@localhost> In-Reply-To: <1130514267.81705.101.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: Load Balancing Outgoing, its possible ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: daniel@dgnetwork.com.br List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2005 16:03:34 -0000 Corey Smith escreveu: >On Fri, 2005-10-28 at 17:19 +0200, G Bryant wrote: > > >>Daniel Dias Gonçalves wrote: >> >> >> >>>It is possible to make this balancing with the PF ? Exists some >>>software that I make this ? Zebra can help me? >>>This type of balancing gives to problems with the navigation of the >>>user of NAT or IP valid ? >>>If it is possible, wanted to see examples with rules. >>> >>> >>> > >It would be much better to do per flow load balancing then per packet. >With per packet your TCP flows will arrive out of order which is a bad >situation since it will lead to a large number of retransmissions and >zero-window acknowledgments. > >The only tunable to help correct that is to allow selective >acknowledgments. > >You are going to get much higher utilization on your load balanced lines >by using per flow with multiple TCP connections. > >Anybody know how to implement per flow load balancing in FreeBSD? Are >multiple default routes supported? > >It would be beautiful if you could put multiple routes with the same >metric into the kernel and then the kernel would enable per flow load >balancing of the routes... > > It would be very good if could make this. >-Corey Smith > > > > Which the solution? -- Daniel Dias Gonçalves DGNET Network Solutions daniel@dgnetwork.com.br (37) 99824809 From owner-freebsd-net@FreeBSD.ORG Fri Oct 28 16:23: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 B867816A41F; Fri, 28 Oct 2005 16:23:47 +0000 (GMT) (envelope-from csmith@bonddesk.com) Received: from msmisps01.bonddesk.com (msmisps01.bonddesk.com [12.47.70.99]) by mx1.FreeBSD.org (Postfix) with ESMTP id 238A443D45; Fri, 28 Oct 2005 16:23:47 +0000 (GMT) (envelope-from csmith@bonddesk.com) Received: from mimail.bdg.local ([10.132.16.100]) by chmail.bdg.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 12:23:45 -0400 Received: from 10.133.16.35 ([10.133.16.35]) by mimail.bdg.local ([10.132.16.100]) with Microsoft Exchange Server HTTP-DAV ; Fri, 28 Oct 2005 16:23:44 +0000 Received: from csmith-dt.bdg.local by mimail.bonddesk.com; 28 Oct 2005 12:23:44 -0400 From: Corey Smith To: daniel@dgnetwork.com.br In-Reply-To: <43624BCE.6010907@dgnetwork.com.br> References: <4361FE7E.50607@dgnetwork.com.br> <43624181.5010305@roamingsolutions.net> <1130514267.81705.101.camel@localhost> <43624BCE.6010907@dgnetwork.com.br> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Oct 2005 12:23:44 -0400 Message-Id: <1130516624.81705.107.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port X-OriginalArrivalTime: 28 Oct 2005 16:23:46.0091 (UTC) FILETIME=[F85A37B0:01C5DBDB] Cc: freebsd-net@freebsd.org, freebsd-pf@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: Load Balancing Outgoing, its possible ? 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, 28 Oct 2005 16:23:47 -0000 On Fri, 2005-10-28 at 14:03 -0200, Daniel Dias Gon=E7alves wrote: > It would be very good if could make this. > > Which the solution? Linux supports this feature if you build advanced routing options into the kernel. The only FreeBSD code I've seen to do something like this is at: http://www.dsm.fordham.edu/~tanzer/multipath/=20 Unfortunately it hasn't been updated past FreeBSD 4.8. Maybe a FreeBSD winter-of-code project? :) Any takers? -Corey Smith From owner-freebsd-net@FreeBSD.ORG Fri Oct 28 17:02: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 A15E016A41F; Fri, 28 Oct 2005 17:02:03 +0000 (GMT) (envelope-from gbryant@roamingsolutions.net) Received: from basillia.speedxs.net (basillia.speedxs.net [83.98.255.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8A2C43D45; Fri, 28 Oct 2005 17:02:02 +0000 (GMT) (envelope-from gbryant@roamingsolutions.net) Received: from ongers.net (ongers.speedxs.nl [83.98.237.210]) by basillia.speedxs.net (Postfix) with ESMTP id 9B75840C7; Fri, 28 Oct 2005 18:48:43 +0200 (CEST) Received: from (165.146.215.66 [165.146.215.66]) by MailEnable Inbound Mail Agent with ESMTP; Fri, 28 Oct 2005 19:07:43 +0200 Message-ID: <436259A1.3090704@roamingsolutions.net> Date: Fri, 28 Oct 2005 19:02:25 +0200 From: G Bryant User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: daniel@dgnetwork.com.br, FreeBSD , FreeBSD References: <4361FE7E.50607@dgnetwork.com.br> <43624181.5010305@roamingsolutions.net> <43624A5E.7010002@dgnetwork.com.br> In-Reply-To: <43624A5E.7010002@dgnetwork.com.br> Content-Type: multipart/mixed; boundary="------------090402040307030304090109" X-Antivirus: avast! (VPS 0543-2, 2005/10/27), Outbound message X-Antivirus-Status: Clean Cc: Subject: Re: Load Balancing Outgoing, its possible ? 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, 28 Oct 2005 17:02:03 -0000 This is a multi-part message in MIME format. --------------090402040307030304090109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Daniel Dias Gonçalves wrote: > G Bryant escreveu: > >> Daniel Dias Gonçalves wrote: >> >>> >>> Complicated ? Its possible ? >>> >>> TELECOM >>> LOAD SHARING PER PACKET >>> ------------------------------------------------------------------------------------------ >>> >>> | | | | >>> | | >>> | | | | >>> | | >>> ------------------------------------- >>> ------------------------------------- >>> CISCO 2600 (6mbps) HAUWEI (6mbps) >>> LOAD SHARING PER PACKET LOAD SHARING PER >>> PACKET >>> ------------------------------------- >>> ------------------------------------- >>> Ethernet (64.XX.XX.1/30) Ethernet >>> (65.XX.XX.1/30) >>> | | >>> | | >>> | | >>> XL0 (64.XX.XX.2/30) XL1 >>> (65.XX.XX.2/30) >>> ------------------------------------------------------------------------------------------ >>> >>> FREEBSD 5.4 + PF >>> ------------------------------------------------------------------------------------------ >>> >>> XL2 (192.168.0.254/24, 64.XX.XX.5/30, 65.XX.XX.5/30) >>> | >>> | >>> ------------------ >>> SWITCH >>> ------------------------------- IP: 65.XX.XX.6/30 >>> >>> ------------------ >>> GW: 65.XX.XX.5 >>> / \ >>> / \ >>> IP: 192.168.0.10/24 IP: >>> 64.XX.XX.6/30 >>> GW: 192.168.0.254 GW: 64.XX.XX.5 >>> and more clients ... I need >>> load balancing outgoing traffic from: >>> 192.168.0.0/24 ( NAT ) >>> and 64.XX.XX.0/24, 65.XX.XX.0/24 >>> >>> It is possible to make this balancing with the PF ? Exists some >>> software that I make this ? Zebra can help me? >>> This type of balancing gives to problems with the navigation of the >>> user of NAT or IP valid ? >>> If it is possible, wanted to see examples with rules. >>> >>> Thanks, >>> >> If you do not manage to come right with PF, I have a working example >> of a similar setup using IPFW & natd. >> Let me know if you would like the config files. >> Regards >> Graham >> >> >> > Send me yours config and net scheme. > Thanks ;-) > A system I recently installed is up and running. here are the config files. netmon2.sh runs from crontab to monitor the links and switches the traffic to the good link if one link fails. Also uses squid proxy and bandwidth management for internal users. Regards Graham --------------090402040307030304090109 Content-Type: text/plain; name="rc.conf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rc.conf" hostname="xx.yy.zz" # Configure the internal network ifconfig_vr0="inet 192.168.1.1 netmask 255.255.255.0" # Configure the external networks (connected to the internet) #ifconfig_rl0="DHCP" ifconfig_rl0="inet 192.168.8.70 netmask 255.255.255.0" ifconfig_rl0_alias0="inet 192.168.0.99 netmask 255.255.255.0" defaultrouter="192.168.8.1" #ifconfig_rl1="inet 192.168.0.99 netmask 255.255.255.0" #ifconfig_rl1="DHCP" # - Enabling the FreeBSD Firewall, IPFirewall (IPFW)- gateway_enable="YES" firewall_enable="YES" firewall_script="/etc/ipfw.rules" firewall_logging="YES" # - Enabling the specific NAT server for IPFW natd_enable="YES" natd_flags="-f /etc/natd1.conf" natd2_enable="YES" natd2_flags="-f /etc/natd2.conf" sshd_enable="YES" usbd_enable="NO" rwhod_enable="NO" dhcpd_enable="YES" dhcpd_flags="-cf /usr/local/etc/dhcpd.conf -q" #Enable the proxy server squid_enable="YES" ntpd_enable="YES" ntpd_flags="-c /etc/ntp.conf" # Bandwidth monitoring with html graphs bandwidthd_enable="YES" # jftpgw ftp proxy for anonymous ftp proxy-cache jftpgw_enable="YES" # Dynamic DNS Client ddclient_enable="YES" # Load the script to hook the two external nic's together netmon1_enable="YES" --------------090402040307030304090109 Content-Type: text/plain; name="netmon1.sh" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netmon1.sh" #!/bin/sh # Load the kernel modules kldload ng_ether kldload ng_one2many ifconfig rl0 down ifconfig rl1 down # Plumb nodes together ngctl mkpeer rl0: one2many upper one ngctl connect rl0: rl0:upper lower many0 ngctl connect rl1: rl0:upper lower many1 # Allow rl0 to xmit / recv rl0 frames ifconfig rl1 promisc ngctl msg rl1: setautosrc 0 # Configure to transmit ngctl msg rl0:upper setconfig "{xmitAlg=2 failAlg=1 enabledLinks =[ 1 1 ] }" echo "Now up the interfaces again" ifconfig rl0 up ifconfig rl1 up ifconfig rl0 inet 192.168.8.70 netmask 255.255.255.0 ifconfig rl0 inet 192.168.0.99 netmask 255.255.255.0 alias route delete default route add default 192.168.8.1 echo "Done" --------------090402040307030304090109 Content-Type: text/plain; name="netmon2.sh" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netmon2.sh" #!/bin/sh target="196.7.0.138" ext_gw1="192.168.8.1" ext_gw2="192.168.0.1" # Setup route to ping through route -q add -host $target $ext_gw1 # Test link one through ext_gw1 ping1=$( ping -q -c 3 -f -s 8 -o -t 2 196.7.0.138 | grep "packet loss" | cut -c24-24 ) # Test link two through ext_gw2 route -q delete $target route -q add -host $target $ext_gw2 ping2=$( ping -q -c 3 -f -s 8 -o -t 2 196.7.0.138 | grep "packet loss" | cut -c24-24 ) # Remove route route -q delete $target # Configure the ipfw sets as per network route availability if [ "$ping1" != "0" ]; then if [ "$ping2" = "1" ]; then ipfw set enable 1 2 12 else ipfw set enable 1 ipfw set disable 2 12 fi else if [ "$ping2" != "0" ]; then ipfw set disable 1 12 ipfw set enable 2 else # echo "enabling everything to wait for network recovery" ipfw set enable 1 2 12 fi fi --------------090402040307030304090109 Content-Type: text/plain; name="natd1.conf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="natd1.conf" alias_address 192.168.8.70 pid_file /var/run/natd1.pid port natd1 --------------090402040307030304090109 Content-Type: text/plain; name="natd2.conf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="natd2.conf" alias_address 192.168.0.99 pid_file /var/run/natd2.pid port natd2 --------------090402040307030304090109 Content-Type: text/plain; name="ipfw.rules" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ipfw.rules" #!/bin/sh ################ Start of IPFW rules file ############################### # Flush out the list before we begin. ipfw -q -f flush # Set rules command prefix cmd="ipfw -q add" bwm="ipfw -q pipe" skip="skipto 8000" ext_if1="rl0" # public interface name of NIC ext_if2="rl0" int_if="vr0" # private interface name of NIC ext_ip1="192.168.8.70" ext_ip2="192.168.0.99" ext_gw1="192.168.8.1" ext_gw2="192.168.0.1" # Setup the different Sets to be used for different connection options ipfw -q set disable 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 # Initially only enable set 1 (and 2 and 12 when we have 2 WAN links) ipfw -q set enable 1 2 5 12 # Specify which ip addresses get what bandwidth # Can also tell this dhcp server to give certain addresses to selected mac # addresses in file /usr/local/etc/dhcpd.conf u512k="192.168.10.2" # Users given 512kb/s link u256k="192.168.1.0/24{2-254}" # Users given 256kb/s link u128k="192.168.10.2" # Users given 128kb/s link u64k="192.168.10.2" # Users given 64kb/s link (default from dhcp) $cmd 10 allow ip from any to any ################################################################# # Check and drop packets that are appearing to come from # the destination LAN i.e. a spoofed source ip address $cmd 100 deny ip from any to any not antispoof in ################################################################# # No restrictions on Loopback Interface # Protect spoofing to localhost $cmd allow ip from any to any via lo0 $cmd deny ip from any to 127.0.0.0/8 $cmd deny ip from 127.0.0.0/8 to any ################################################################# # check if packet is inbound and nat address if it is $cmd 1000 divert natd1 ip from any to $ext_ip1 in $cmd 1000 divert natd2 ip from any to $ext_ip2 in #$cmd skipto 5000 ip from any to any in via $ext_if1 #$cmd skipto 5000 ip from any to any in via $ext_if2 ################################################################ # Divert incoming http and ftp traffic to the proxy (squid and jftpgw) $cmd set 5 fwd 192.168.1.1,3128 tcp from 192.168.1.0/24 to any 80 in via $int_if #$cmd fwd 192.168.1.1,2370 tcp from 192.168.1.0/24 to any 21 via $int_if ################################################################# # Allow the rest of the LAN traffic in and out $cmd allow ip from any to any via $int_if ################################################################ ############## Bandwidth Management ############################ ################################################################ # Setup up pipes for each of the user groups ################################################################ # Users with 512Kb / 256Kb access (in / out) ################################################################ $cmd pipe 10 ip from any to $u512k in via $ext_if1 $cmd pipe 11 ip from $u512k to any out via $ext_if1 $bwm 10 config mask dst-ip 0x000000ff bw 512Kbit/s queue 4KBytes $bwm 11 config mask src-ip 0x000000ff bw 256Kbit/s queue 3KBytes ################################################################ # Users with 256Kb / 128Kb access ################################################################ $cmd pipe 20 ip from any to $u256k in via $ext_if1 $cmd pipe 21 ip from $u256k to any out via $ext_if1 $bwm 20 config mask dst-ip 0x000000ff bw 256Kbit/s queue 4KBytes $bwm 21 config mask src-ip 0x000000ff bw 128Kbit/s queue 3KBytes ################################################################ # Users with 128Kb / 64Kb access ################################################################ $cmd pipe 30 ip from any to $u128k in via $ext_if1 $cmd pipe 31 ip from $u128k to any out via $ext_if1 $bwm 30 config mask dst-ip 0x000000ff bw 128Kbit/s queue 4KBytes $bwm 31 config mask src-ip 0x000000ff bw 64Kbit/s queue 3KBytes ################################################################ # Users with 64Kb / 56Kb access ################################################################ $cmd pipe 40 ip from any to $u64k in via $ext_if1 $cmd pipe 41 ip from $u64k to any out via $ext_if1 $bwm 40 config mask dst-ip 0x000000ff bw 64Kbit/s queue 14KBytes $bwm 41 config mask src-ip 0x000000ff bw 56Kbit/s queue 12KBytes # 40 was set to 7KB # 41 was set to 6KB ################################################################# # Interface facing Public Internet (Outbound Section) ################################################################# # Allow out access to my ISP's Domain name server. # Get the IP addresses from /etc/resolv.conf file #$cmd $skip UDP from any to { 196.7.0.138 or 196.28.86.2 or 196.28.86.3 or 196.25.1.1 } 53 out #$cmd allow udp from me to any 53 out # rather use working adsl line out $cmd $skip udp from any to any 53 out # Allow this box out access to my ISP's DHCP server (or adsl router) # to get it's network configuration settings (IP, DNS, etc). $cmd $skip udp from me to any 67 out # Allow skype connections out # Allow ntp time server out $cmd $skip UDP from any to any 80,443,123,1024-65535 out $cmd $skip UDP from any 80,443,1024-65535 to any out $cmd $skip tcp from any 1024-65535 to any 1024-65535 out # Allow me to reach local routers from this box (tunneled via ssh) $cmd allow tcp from me to 192.168.0.0/16 80 out # Allow out www, ftp from me or from proxy out $cmd $skip tcp from me to any 20,21,80 out # Natting because of the 2 outgoing lines # Allow out secure www function https over TLS SSL # Allow out send & get email function (GMail uses ports 587, 995) # Allow out MSN messenger # Allow out Time, nntp news (i.e. news groups), # SSH (secure FTP, Telnet, and SCP), whois $cmd $skip tcp from any to any 443,25,110,587,995,1863,37,119,22,43 out # Allow out regular ftp access (not via proxy) $cmd $skip tcp from any to any 20,21,80 out # Allow out ping $cmd $skip icmp from 192.168.1.0/24 to any out icmptypes 3,8 $cmd allow icmp from me to any out icmptypes 3,8 $cmd allow icmp from me to 192.168.0.0/16 out # Allow external ssh connection back out $cmd $skipto tcp from me 22 to any out # Allow external web traffic from internal servers back out $cmd $skip tcp from 192.168.1.8 80,443 to any out # Allow external mail traffic from internal servers back out $cmd $skip tcp from 192.168.1.3 25,110 to any out # Allow external ftp, vpn connection traffic from internal servers back out $cmd $skip tcp from 192.168.1.9 20,21,1723 to any out # Allow out FreeBSD (make install & CVSUP) functions # Give user root "GOD" privileges. $cmd allow ip from me to any out uid root # Deny the rest out $cmd deny log ip from any to any out ################################################################# # Interface facing Public Internet (Inbound Section) # Interrogate packets originating from the public Internet # destine for this gateway server or the private network. ################################################################# # Deny all inbound traffic from non-routable reserved address spaces #$cmd 300 deny all from 192.168.0.0/16 to any in via $ext_if1 #RFC 1918 private IP $cmd deny all from 172.16.0.0/12,10.0.0.0/8,0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,204.152.64.0/23,224.0.0.0/3 to any in #RFC 1918 private IP #RFC 1918 private IP #DHCP auto-config #reserved for docs #Sun cluster #Class D & E multicast # Deny ident # Deny all Netbios service. 137=name, 138=datagram, 139=session # Netbios is MS/Windows sharing services. # Block MS/Windows hosts2 name server requests 81 $cmd deny all from any to any 113,137,138,139,81 in # Allow traffic in from ISP's DHCP server. This rule must contain # the IP address of your ISP's DHCP server as it's the only # authorized source to send this packet type. $cmd allow udp from 192.168.8.1,192.168.0.1 to any 68,1900,5678 in # Allow dns lookups back in $cmd allow udp from any 53,67 to 192.168.1.0/24 in $cmd allow udp from any 53,67 to me in # Allow skype connections in $cmd allow udp from any 80,123,443,1024-655353 to 192.168.1.0/24 in $cmd allow udp from any to 192.168.1.0/24 80,443,1024-655353 in $cmd deny log udp from any to any in # Deny the rest $cmd allow tcp from any 1024-65535 to 192.168.1.0/24 1024-65535 in # Allow in standard www function because I have Apache server - or is there an internal webserver? # Allow Webmin connections from close-by $cmd allow tcp from { 192.168.8.0/24 or 192.168.0.0/24 } to me 10000,80 in $cmd allow tcp from any to 192.168.1.8,192.168.1.9 80,443 in # Allow outgoing ftp, web traffic (via proxy) back in $cmd allow tcp from any 80 to me in # Allow in regular ftp, http access if proxy is off $cmd allow tcp from any 20,21,80 to 192.168.1.0/24 in # Allow in secure www function https over TLS SSL # Allow in send & get email function (GMail uses ports 587, 995) # Allow in MSN messenger # Allow in Time, nntp news (i.e. news groups), # SSH (secure FTP, Telnet, and SCP), whois $cmd allow tcp from any 443,25,110,587,995,1863,37,119,22,43 to any in # Allow external web traffic in to internal servers $cmd allow tcp from any to 192.168.1.8 80,443 in keep-state # Allow external mail traffic in to internal servers $cmd allow tcp from any to 192.168.1.3 25,110 in keep-state # Allow external ftp, vpn connection traffic in to internal servers $cmd allow tcp from any to 192.168.1.9 20,21,1723 in keep-state # Allow in secure FTP, Telnet, and SCP from public Internet $cmd allow tcp from { 192.168.0.0/24 or 192.168.1.0/24 or 192.168.8.0/24 } to me 22 in #setup limit src-addr 3 $cmd allow tcp from any to me 22 in setup limit src-addr 3 # Deny the rest to me $cmd deny log tcp from any to me in #Allow in ICMP (ping) from public networks close by only. $cmd allow icmp from 196.7.0.138,196.25.1.1,196.4.160.7 to me in icmptypes 0,3,11 $cmd allow icmp from any to 192.168.1.0/24 in icmptypes 0,3,11 $cmd allow icmp from any to me in icmptypes 0,3,11 $cmd allow icmp from 192.168.0.0/16 to me in #Deny the rest icmp $cmd deny icmp from any to any in # Reject & Log all unauthorized incoming connections from the public Internet (/var/log/security) $cmd deny log all from any to any in ### ********************************************************* # This is skipto location for outbound stateful rules $cmd 8000 skipto 9000 tcp from any to any out setup $cmd 8010 skipto 9000 udp from any to any out $cmd 8020 skipto 9000 icmp from any to any out $cmd 8100 tee natd1 ip from any to any out $cmd 8150 check-state $cmd 8160 allow ip from me 20,21,22,25,80,110,443,1723 to any out $cmd 8200 divert natd2 ip from any to any out $cmd 8250 check-state $cmd 8260 allow ip from me 20,21,22,25,80,110,443,1723 to any out $cmd 8400 deny ip from any to any out $cmd 9000 set 12 prob 0.5 skipto 9500 ip from any to any out $cmd 9100 set 1 divert natd1 ip from any to any out $cmd 9200 set 1 fwd 192.168.8.1 ip from any to any out keep-state $cmd 9500 set 2 divert natd2 ip from any to any out $cmd 9600 set 2 fwd 192.168.0.1 ip from any to any out keep-state # Everything else is denied by default # deny and log all packets that fell through to see what they are $cmd 9999 deny log all from any to any ipfw -q delete 10 ################ End of IPFW rules file ############################### --------------090402040307030304090109-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 28 19:09: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 91F5116A41F for ; Fri, 28 Oct 2005 19:09:22 +0000 (GMT) (envelope-from dcornejo@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37E0F43D46 for ; Fri, 28 Oct 2005 19:09:22 +0000 (GMT) (envelope-from dcornejo@gmail.com) Received: by zproxy.gmail.com with SMTP id x3so494618nzd for ; Fri, 28 Oct 2005 12:09:21 -0700 (PDT) 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=ZxxGqd142LEEMbdLjahP1eB6ku3+rGPeh0lFgS4bKMk3na5bQ5Ic5rmYUnS2TzY7E+RzKmJwTo8W0sE4JnuFwHHjrJasj/dfq9VQWWjhu1cx/6tj6gjqmNI4rqlhj0/zgiPOGMolIggG6246ZhN4YnHpyM4322zbMhGDPR8/G30= Received: by 10.36.222.9 with SMTP id u9mr527053nzg; Fri, 28 Oct 2005 12:09:21 -0700 (PDT) Received: by 10.36.18.17 with HTTP; Fri, 28 Oct 2005 12:09:20 -0700 (PDT) Message-ID: <6b8e8f4f0510281209l57703c36j817ae577ba1e3a77@mail.gmail.com> Date: Fri, 28 Oct 2005 09:09:20 -1000 From: spoggle 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: distributed bridging 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, 28 Oct 2005 19:09:22 -0000 Greetings, I'm trying to create a configuration that would bridge interfaces on different hosts. Each host would have at least two interfaces, one would be the inter-host connection, the remaining would be the bridged interfaces, so that a packet appearing on host a's bridged interface would also appear on host b, c, etc. bridged interfaces and vice versa. My equipment to try this is on order, so it's still somewhat of a brain exercise. I would like to use if_bridge (for it's STP) and I was thinking of bridging the local interfaces and then using netgraph (eiface?) connected to some other plumbing like l2tp to connect the remote bridges together. Does this sound feasible? Anyone have any other suggestions on how to pull this off? I've also considered hacking if_bridge to allow the configuration of remote bridges as pseudo ports, but not sure I'll have time. spoggle From owner-freebsd-net@FreeBSD.ORG Fri Oct 28 19:22: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 B021316A41F for ; Fri, 28 Oct 2005 19:22:03 +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 49B9C43D46 for ; Fri, 28 Oct 2005 19:22:03 +0000 (GMT) (envelope-from regnauld@moof.catpipe.net) Received: from localhost (localhost [127.0.0.1]) by localhost.catpipe.net (Postfix) with ESMTP id B93231B7AC; Fri, 28 Oct 2005 21:22:01 +0200 (CEST) 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 47378-07; Fri, 28 Oct 2005 21:22:00 +0200 (CEST) Received: by moof.catpipe.net (Postfix, from userid 1001) id 3BF091B7AB; Fri, 28 Oct 2005 21:22:00 +0200 (CEST) Date: Fri, 28 Oct 2005 21:22:00 +0200 From: Phil Regnauld To: spoggle Message-ID: <20051028192159.GA47396@moof.catpipe.net> References: <6b8e8f4f0510281209l57703c36j817ae577ba1e3a77@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6b8e8f4f0510281209l57703c36j817ae577ba1e3a77@mail.gmail.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: distributed bridging 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, 28 Oct 2005 19:22:03 -0000 spoggle (dcornejo) writes: > Does this sound feasible? Anyone have any other suggestions on how to > pull this off? I've done it with openvpn and bridging a tap device on both ends. From owner-freebsd-net@FreeBSD.ORG Fri Oct 28 19:28: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 033B616A420 for ; Fri, 28 Oct 2005 19:28:36 +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 BDD9743D46 for ; Fri, 28 Oct 2005 19:28:35 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.117]) ([10.251.23.117]) by a50.ironport.com with ESMTP; 28 Oct 2005 12:28:35 -0700 X-IronPort-Anti-Spam-Filtered: true Message-ID: <43627BE3.9080905@elischer.org> Date: Fri, 28 Oct 2005 12:28:35 -0700 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: spoggle References: <6b8e8f4f0510281209l57703c36j817ae577ba1e3a77@mail.gmail.com> In-Reply-To: <6b8e8f4f0510281209l57703c36j817ae577ba1e3a77@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: distributed bridging 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, 28 Oct 2005 19:28:36 -0000 spoggle wrote: >Greetings, > >I'm trying to create a configuration that would bridge interfaces on >different hosts. Each host would have at least two interfaces, one >would be the inter-host connection, the remaining would be the bridged >interfaces, so that a packet appearing on host a's bridged interface >would also appear on host b, c, etc. bridged interfaces and vice >versa. > >My equipment to try this is on order, so it's still somewhat of a >brain exercise. > >I would like to use if_bridge (for it's STP) and I was thinking of >bridging the local interfaces and then using netgraph (eiface?) >connected to some other plumbing like l2tp to connect the remote >bridges together. > >Does this sound feasible? Anyone have any other suggestions on how to >pull this off? > >I've also considered hacking if_bridge to allow the configuration of >remote bridges as pseudo ports, but not sure I'll have time. > > on machine A you have: NIC A 1.1.1.1 NIC B 10.0.0.1 on machine B you have: NIC A 2.2.2.2 NIC B 10.0.0.2 On each machine use a modification of /usr/share/examples/netgraph/ether.bridge so that one link of each bridge is set to an ng_ksocket instead of a real interface. then send messages to each or the sockets to connect to each other with UDP. how to do this is in /usr/share/examples/netgraph/udp.tunnel by combining the two you should create a tunnel between the two bridges which should result in a single bridged network. that should be about all you need. >spoggle >_______________________________________________ >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 Fri Oct 28 20:04: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 62E5F16A41F for ; Fri, 28 Oct 2005 20:04:21 +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 29D6E43D45 for ; Fri, 28 Oct 2005 20:04:20 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.117]) ([10.251.23.117]) by a50.ironport.com with ESMTP; 28 Oct 2005 13:04:19 -0700 X-IronPort-Anti-Spam-Filtered: true Message-ID: <43628443.1020908@elischer.org> Date: Fri, 28 Oct 2005 13:04:19 -0700 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: Julian Elischer References: <6b8e8f4f0510281209l57703c36j817ae577ba1e3a77@mail.gmail.com> <43627BE3.9080905@elischer.org> In-Reply-To: <43627BE3.9080905@elischer.org> Content-Type: multipart/mixed; boundary="------------050304070805070003070505" Cc: freebsd-net@freebsd.org, spoggle Subject: Re: distributed bridging [script] 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, 28 Oct 2005 20:04:21 -0000 This is a multi-part message in MIME format. --------------050304070805070003070505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Julian Elischer wrote: > spoggle wrote: > >> Greetings, >> >> I'm trying to create a configuration that would bridge interfaces on >> different hosts. Each host would have at least two interfaces, one >> would be the inter-host connection, the remaining would be the bridged >> interfaces, so that a packet appearing on host a's bridged interface >> would also appear on host b, c, etc. bridged interfaces and vice >> versa. >> >> My equipment to try this is on order, so it's still somewhat of a >> brain exercise. >> >> I would like to use if_bridge (for it's STP) and I was thinking of >> bridging the local interfaces and then using netgraph (eiface?) >> connected to some other plumbing like l2tp to connect the remote >> bridges together. >> >> Does this sound feasible? Anyone have any other suggestions on how to >> pull this off? >> >> I've also considered hacking if_bridge to allow the configuration of >> remote bridges as pseudo ports, but not sure I'll have time. >> >> > > on machine A you have: > NIC A 1.1.1.1 > NIC B 10.0.0.1 > on machine B you have: > > NIC A 2.2.2.2 > NIC B 10.0.0.2 > > > On each machine use a modification of > /usr/share/examples/netgraph/ether.bridge > > so that one link of each bridge is set to an ng_ksocket instead of a > real interface. > then send messages to each or the sockets to connect to each other > with UDP. > > how to do this is in /usr/share/examples/netgraph/udp.tunnel > > by combining the two you should create a tunnel between the two > bridges which > should result in a single bridged network. > > > that should be about all you need. here's a completely untested script. swap the addresses on each end of the bridge (and probably remove one of the bridged ethernet ports ans you probably only have one internal NIC on each machine (remove ed0)) > > > > > > >> spoggle >> _______________________________________________ >> 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" >> >> > _______________________________________________ > 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" --------------050304070805070003070505 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="remote.bridge" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="remote.bridge" #!/bin/sh # $FreeBSD: src/share/examples/netgraph/ether.bridge,v 1.1.2.2 2001/07/19 05:45:03 dd Exp $ # This script sets up an Ethernet bridging network across multiple # Ethernet interfaces using the ng_bridge(4) and ng_ether(4) netgraph # node types. # # To use this script: # # 0. Make your own copy of this example script # # 1. Give your bridging network a name by editing the definition of # ${BRIDGE_NAME} below. It must be a valid netgraph node name. # # 2. Edit the definitions of ${BRIDGE_IFACES} and ${LOCAL_IFACE} # as described below to define your bridging interfaces. # # 3. Run this script with "start" as the command line argument. # # 4. Examine bridging statistics by running this script with "stats" # as the command line argument. # # 5. Stop bridging by running this script with "stop" as the # command line argument. # # To run multiple independent bridging networks, create multiple # copies of this script with different variable definitions. # # Give each bridging network a unique name here BRIDGE_NAME="bnet0" # List the names of the interfaces that you want to bridge across # here in ${BRIDGE_IFACES}. If you want to include the local host # machine as well then set ${LOCAL_IFACE} as well (it may also be # listed in ${BRIDGE_IFACES}). Of course, any ${LOCAL_IFACE} must # be ifconfig(8)ured separately. If you don't want a ${LOCAL_IFACE} # then leave it defined as the emtpy string. # This script sets up a virtual point-to-point WAN link between # two subnets, using UDP packets as the ``WAN connection.'' # The two subnets might be non-routable addresses behind a # firewall. # # Here define the local and remote inside networks as well # as the local and remote outside IP addresses and UDP port # number that will be used for the tunnel. # #BRIDGE_IFACES="ed0 fxp0 fxp1 tunnel1" BRIDGE_IFACES="fxp0 tunnel1" LOCAL_IFACE="fxp0" LOC_INTERIOR_IP=192.168.1.1 LOC_EXTERIOR_IP=1.1.1.1 REM_INTERIOR_IP=192.168.2.1 REM_EXTERIOR_IP=2.2.2.2 REM_INSIDE_NET=192.168.2.0 UDP_TUNNEL_PORT=4028 #################################################################### #### Everything below this point should not need to be modified #### #################################################################### # Routine to verify node's existence bridge_verify() { ngctl info ${BRIDGE_NAME}: >/dev/null 2>&1 if [ $? -ne 0 ]; then echo "${BRIDGE_NAME}: bridge network not found" exit 1 fi } # Routine to get and display link stats bridge_linkstats() { STATS=`ngctl msg ${BRIDGE_NAME}: getstats $1` if [ $? -ne 0 ]; then exit 1 fi echo "${STATS}" | fmt 2 | awk '/=/ { fl=index($0, "="); \ printf "%20s = %s\n", substr($0, 0, fl - 1), substr($0, fl + 1); }' } # Start/restart routine bridge_start() { # Load netgraph KLD's as necessary for KLD in ng_ether ng_bridge ng_ksocket; do if kldstat -v | grep -qw ${KLD}; then else echo -n "Loading ${KLD}.ko... " kldload ${KLD} || exit 1 echo "done" fi done # Reset all interfaces bridge_stop # Verify all interfaces exist for ETHER in ${BRIDGE_IFACES} ${LOCAL_IFACE}; do case $ETHER in tunnel*) # nothing to do (I think) ;; *) if ngctl info ${ETHER}: >/dev/null 2>&1; then ifconfig ${ETHER} up || exit 1 else echo "Error: interface ${ETHER} does not exist" exit 1 fi ;; esac done # Create new ng_bridge(4) node, attached to the first interface FIRSTIF=`echo ${BRIDGE_IFACES} | awk '{ print $1 }'` ngctl mkpeer ${FIRSTIF}: bridge lower link0 || exit 1 ngctl name ${FIRSTIF}:lower ${BRIDGE_NAME} || exit 1 # Attach other interfaces as well LINKNUM=0 for ETHER in ${BRIDGE_IFACES}; do case $ETHER in tunnel*) # Attach a UDP socket to the ``inet'' # hook of the interface node # using the ng_ksocket(8) node type. # ngctl mkpeer ${BRIDGE_NAME}: ksocket \ link${LINKNUM} inet/dgram/udp # Bind the UDP socket to the local external # IP address and port ngctl msg ng0:inet bind \ inet/${LOC_EXTERIOR_IP}:${UDP_TUNNEL_PORT} # Connect the UDP socket to the peer's # external IP address and port ngctl msg ng0:inet connect \ inet/${REM_EXTERIOR_IP}:${UDP_TUNNEL_PORT} ;; *) if [ ${LINKNUM} != 0 ]; then ngctl connect ${ETHER}: ${BRIDGE_NAME}: \ lower link${LINKNUM} || exit 1 fi ;; esac LINKNUM=`expr ${LINKNUM} + 1` done # Hook up local interface, if any if [ "${LOCAL_IFACE}" != "" ]; then ngctl connect ${LOCAL_IFACE}: ${BRIDGE_NAME}: \ upper link${LINKNUM} || exit 1 fi # Set all interfaces in promiscuous mode and don't overwrite src addr for ETHER in ${BRIDGE_IFACES}; do case $ETHER in tunnel*) # nothing to do (I think) ;; *) ngctl msg ${ETHER}: setpromisc 1 || exit 1 ngctl msg ${ETHER}: setautosrc 0 || exit 1 ;; esac done } # Stop routine bridge_stop() { ngctl kill ${BRIDGE_NAME}: >/dev/null 2>&1 for ETHER in ${BRIDGE_IFACES} ${LOCAL_IFACE}; do ngctl kill ${ETHER}: >/dev/null 2>&1 done } # Stats routine bridge_stats() { # Make sure node exists bridge_verify echo "" echo "Statistics for bridging network ${BRIDGE_NAME}:" echo "" LINKNUM=0 for ETHER in ${BRIDGE_IFACES}; do echo "Network interface ${ETHER}:" bridge_linkstats ${LINKNUM} LINKNUM=`expr ${LINKNUM} + 1` done if [ "${LOCAL_IFACE}" != "" ]; then echo "Local host interface ${LOCAL_IFACE}:" bridge_linkstats ${LINKNUM} fi } # Main entry point case $1 in start) bridge_start ;; stats) bridge_verify bridge_stats ;; stop) bridge_verify bridge_stop ;; *) echo "Usage: ether.bridge [ start | stop | stats ]" exit 1 esac --------------050304070805070003070505-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 28 21:14: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 449B416A41F for ; Fri, 28 Oct 2005 21:14:17 +0000 (GMT) (envelope-from craig@olyun.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EA0F43D45 for ; Fri, 28 Oct 2005 21:14:16 +0000 (GMT) (envelope-from craig@olyun.gank.org) Received: by ion.gank.org (mail, from userid 1001) id 9212A2D060; Fri, 28 Oct 2005 16:14:16 -0500 (CDT) Date: Fri, 28 Oct 2005 16:14:16 -0500 From: Craig Boston To: SUZUKI Shinsuke Message-ID: <20051028211416.GA59989@nowhere> References: <20051028012957.GA50419@nowhere> <20051028040901.GA47012@nowhere> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: 6.0-RC1 IPv6 losing local subnet route 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, 28 Oct 2005 21:14:17 -0000 On Sat, Oct 29, 2005 at 12:04:53AM +0900, SUZUKI Shinsuke wrote: > I tried the same test using my PC with fxp drivers, but your phenomena > did not happen in my environment (at least for five hours). > > Maybe the configured prefix was regarded as off-link by some reason. > (it is theoretically possible in IPv6, but I'm not sure whether it > really happens in your case) I don't think this is the case, ndp looks normal: 2002:abcd:ef01:5555::/64 if=em1 flags=LO vltime=infinity, pltime=infinity, expire=Never, ref=0 No advertising router [ followed by a whole bunch of link local addresses from all my vlans on a different interface ] However, I think I've isolated the trigger. I noticed that on bootup, the route was _always_ missing. There was also duplicate ifconfig output -- once from rc.d/netif and once from devd upon getting "link up". Knowing that, I can cause it to happen on command by manually re-configuring an interface with an address it already has: With em1 up but not configured yet: # ifconfig em1 inet6 2002:abcd:ef01:5555::20 (routes are all normal) # ifconfig em1 inet6 2002:abcd:ef01:5555::20 (prefix route disappears) It's also been a lot more stable today than yesterday. However yesterday I was moving some cables around so there were lots of link down / up events. My guess is that devd was dutifully reconfiguring the interface on link up and causing the random drops. There is a slight delay between the second ifconfig and the route disappearing -- less than 0.5s. During that window I managed to capture the following seemingly inconsistent output fron ndp -p: 2002:abcd:ef01:5555::/64 if=em1 flags=LO vltime=infinity, pltime=infinity, expired, ref=0 No advertising router -- Craig From owner-freebsd-net@FreeBSD.ORG Fri Oct 28 23:39:20 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 A6B1716A420; Fri, 28 Oct 2005 23:39:20 +0000 (GMT) (envelope-from vaibhave@cs.utah.edu) Received: from mail-svr1.cs.utah.edu (mail-svr1.cs.utah.edu [155.98.64.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F49E43D45; Fri, 28 Oct 2005 23:39:16 +0000 (GMT) (envelope-from vaibhave@cs.utah.edu) Received: from localhost (localhost [127.0.0.1]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id D66D1346D3; Fri, 28 Oct 2005 17:39:15 -0600 (MDT) Received: from mail-svr1.cs.utah.edu ([127.0.0.1]) by localhost (mail-svr1.cs.utah.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18390-02; Fri, 28 Oct 2005 17:39:14 -0600 (MDT) Received: from trust.cs.utah.edu (trust.cs.utah.edu [155.98.65.28]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id 31223346F2; Fri, 28 Oct 2005 17:39:14 -0600 (MDT) Received: by trust.cs.utah.edu (Postfix, from userid 4969) id 094FE3F6F; Fri, 28 Oct 2005 17:39:13 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by trust.cs.utah.edu (Postfix) with ESMTP id EDD453F6C; Fri, 28 Oct 2005 17:39:13 -0600 (MDT) Date: Fri, 28 Oct 2005 17:39:13 -0600 (MDT) From: Vaibhave Agarwal To: current@freebsd.org In-Reply-To: <20051028105057.J20147@fledge.watson.org> Message-ID: References: <20051027233636.GA39380@dmw.hopto.org> <20051028105057.J20147@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: amavisd-new at cs.utah.edu Cc: freebsd , Robert Watson Subject: How to call a function in the kernel from Local APIC timer handler 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, 28 Oct 2005 23:39:20 -0000 Hi, I need some help with the new local APIC functionality added in FreeBSD 6.0 and above. All the code which I am writing is in FreeBSD kernel. I was using LAPIC one shot timer for scheduling some events in the kernel. The problem is that I cannot call the function in my code, directly from the APIC timer handler, because all the interrupts are disabled in the APIC timer handler ( function is lapic_handle_timer() ), and my function uses a sleep mutex to protect the kernel code I have written. Therefore, I schedule a software interrupt thread, which calls my function later in time. Is there a way, I can call my function instantly from the lapic_handle_timer, bcoz using the software interrupt thread, decreases the accuracy of the scheduler i am using. thanks vaibhave On Fri, 28 Oct 2005, Robert Watson wrote: > On Thu, 27 Oct 2005, Vaibhave Agarwal wrote: > > > How do u disable malloc debugging flags in the userland? I read somewhere > > that " ln -s aj /etc/malloc.conf" disables malloc debugging. How does it > > work? > > > > And how to disable verbose features in the kernel? > > > > Apart from this, are there other ways to make the kernel run faster?? > > The note has now been removed, since it was accurate only through the beta > series. > > "Run faster" is a bit nebulous, as performance optimization is a complex > thing. Since you CC'd the net@ list, I assume you want the networking to run > faster. The usual techniques are: > > - If your workload permits it, run with network stack direct dispatch, > which avoids a context switch into the network stack. Be warned that > this may reduce the opportunities for parallelism between the interrupt > and link layer code and network layer code, so while it improves many > workloads, it won't improve all. Set net.dispatch.direct=1. > > - If your workload benefits from it, consider running with device polling > -- this moves form an interrupt driven network model to a polled network > model, greatly decreasing overhead as a result of avoiding thrashing > interrupt handlers, and allowing you to moderate the load generated by > the network. See polling(4) for details, as this requires a custom > kernel configuration and some careful thought. This is usually best for > routers, etc. Polling may increase the latency of packet processing > based on how frequently polling polls, but substantially increase > throughput. > > - Depending on the workload and hardware, you may want to reconsider > compiling with SMP. I.e., for some workloads, HTT helps, and SMP helps, > and for other workloads, it doesn't. > > - Carefully evaluate your hardware configuration -- if this is about > network performance, you may want to make sure that storage and > networking devices are on separate PCI buses, and that if needed, those > buses are 64-bit. > > - Another common hardware issue is shared interrupts -- for example, on > many motherboards, USB and the on-motherboard network device end up on > the same interrupt, or their interrupts fire simultaneously regardless > of the interrupt numbers. Since the USB code is pretty heavy-weight, > you don't want to run it every time you receive a batch of packets via > an interrupt for gig-e. Compiling out USB in this environment may help. > This problem can be detected using vmstat -i, and seeing if the > interrupt rates for USB and your motherboard network device both look > the same -- i.e., very big. > > - Another common concern with threaded network applications is whether the > thread library model and implementation match the requirements of your > application. FreeBSD provides several thread libraries with different > properties, so you might want to consider changing thread libraries. > > - Recent reports indicate that on some systems, slow time counters are > used during context switches. You may want to consider switching to a > faster time counter if time accuracy is less important to you. In one > measurement, this added 30% performance to loop-back network traffic. > This issue is being actively researched. > > Other than that, you'll need to tell us what you're doing. > > Robert N M Watson > > From owner-freebsd-net@FreeBSD.ORG Sat Oct 29 10:33: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 8151616A41F for ; Sat, 29 Oct 2005 10:33:57 +0000 (GMT) (envelope-from jindui@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id E729D43D48 for ; Sat, 29 Oct 2005 10:33:56 +0000 (GMT) (envelope-from jindui@gmail.com) Received: by wproxy.gmail.com with SMTP id i5so321903wra for ; Sat, 29 Oct 2005 03:33:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; b=qU2xGNP+x1WH7Np8lbYLltcaCLSIU3jSRCYJjw0k5MeyusvgrNEziRrfH+43f2y4AjIORikMzkwABTOcNYYxGWOhX6y0pd4jdfB0uWuEUHJi65XQdtII9jN56EsEU+nn1fZ5pk/i+X5rd6anCQBKGmKbp2yQQ/MTuxPAo8h3wZk= Received: by 10.54.34.18 with SMTP id h18mr379941wrh; Sat, 29 Oct 2005 03:33:56 -0700 (PDT) Received: by 10.54.65.12 with HTTP; Sat, 29 Oct 2005 03:33:56 -0700 (PDT) Message-ID: Date: Sat, 29 Oct 2005 18:33:56 +0800 From: =?GB2312?B?vfC20g==?= To: freebsd-net@freebsd.org In-Reply-To: <435E61AD.8040408@kde.org> MIME-Version: 1.0 References: <31021C278A7A6B4AB95E9A085C355218284807@bjngsmail01> <20051025065014.GY41520@cell.sick.ru> <435E61AD.8040408@kde.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: em(4) patch for test X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jindui@hziee.edu.cn List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2005 10:33:57 -0000 # uname -a FreeBSD gateway. 6.0-RC1 FreeBSD 6.0-RC1 #1: Sun Oct 23 08:13:59 CST 2005 root@gateway :/usr/obj/usr/src/sys/jindui i386 There is a lot errors without patch gateway# netstat -Iem0 1 input (em0) output packets errs bytes packets errs bytes colls 28869 275 19844819 28640 0 20947729 0 28536 462 18889923 28154 0 20148408 0 29057 167 19455113 28642 0 20362968 0 27941 437 18662094 27700 0 19851723 0 25240 1777 16781788 24927 0 17898394 0 27688 0 18493832 27496 0 19654540 0 28549 300 18578671 28144 0 19800341 0 28767 325 18883294 28374 0 19923450 0 29122 155 19812945 28820 0 20889855 0 28334 276 18353204 27967 0 19429505 0 28784 226 19082753 28504 0 20253622 0 28826 217 19318352 28431 0 20450404 0 28349 164 19135731 27997 0 20288743 0 28551 322 19224367 28281 0 20242867 0 25963 1783 17619926 25684 0 18752629 0 23968 0 15843647 23736 0 17048709 0 28657 146 18957744 28262 0 19919993 0 28852 612 18439079 28520 0 19839010 0 28692 157 19033221 28496 0 20158177 0 28607 567 18975000 28278 0 20131672 0 From owner-freebsd-net@FreeBSD.ORG Sat Oct 29 12:23: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 74EF516A41F for ; Sat, 29 Oct 2005 12:23:19 +0000 (GMT) (envelope-from suz@alaxala.net) Received: from pc1.alaxala.kame.net (kame219.kame.net [203.178.141.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBCD043D48 for ; Sat, 29 Oct 2005 12:23:18 +0000 (GMT) (envelope-from suz@alaxala.net) Received: from localhost (localhost [127.0.0.1]) by pc1.alaxala.kame.net (Postfix) with ESMTP id D170762B4; Sat, 29 Oct 2005 21:24:25 +0900 (JST) Received: from pc1.alaxala.kame.net ([127.0.0.1]) by localhost (pc1.alaxala.kame.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63699-04; Sat, 29 Oct 2005 21:24:21 +0900 (JST) Received: from flora220.uki-uki.net (240.163.192.61.tokyo.global.alpha-net.ne.jp [61.192.163.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pc1.alaxala.kame.net (Postfix) with ESMTP id 6F99B62B9; Sat, 29 Oct 2005 21:24:21 +0900 (JST) Date: Sat, 29 Oct 2005 21:22:08 +0900 Message-ID: From: SUZUKI Shinsuke To: craig@olyun.gank.org X-cite: xcite 1.33 In-Reply-To: <20051028211416.GA59989@nowhere> References: <20051028012957.GA50419@nowhere> <20051028040901.GA47012@nowhere> <20051028211416.GA59989@nowhere> User-Agent: Wanderlust/2.15.1 (Almost Unreal) Emacs/22.0 Mule/5.0 (SAKAKI) Organization: Technical Marketing Dept., ALAXALA Networks Corporation MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: amavisd-new at alaxala.kame.net Cc: freebsd-net@freebsd.org Subject: Re: 6.0-RC1 IPv6 losing local subnet route 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, 29 Oct 2005 12:23:19 -0000 Hello all, >>>>> On Fri, 28 Oct 2005 16:14:16 -0500 >>>>> craig@olyun.gank.org(Craig Boston) said: > Knowing that, I can cause it to happen on command by manually > re-configuring an interface with an address it already has: > # ifconfig em1 inet6 2002:abcd:ef01:5555::20 > (routes are all normal) > # ifconfig em1 inet6 2002:abcd:ef01:5555::20 > (prefix route disappears) I could reproduce your problem, and found out the reason: it's a bug, not a feature. In this case, the second ifconfig command removes the old address and then installs the new one (actually the same one again). Within kernel, however, the prefix route is completely removed after 1[s] by nd6_timer() (this 1[s] timer is set in in6.c in6_control() l.710). This route-removing timer is invoked after the addition of new address, and removes the prefix route. (prefix lifetime is not properly managed in case of a statically configured address) Here's the list of possible solutions. I'm now working on the second one. But if you need an immediately solution for 6.0-RELEASE, please consider the first one. - in ifconfig, wait for 1[s] between the removal of the old address and addition of the new address it immediately works, but people has to wait 1[s] for each address assignment... - in kernel, properly manages the reference count of nd_prefix and remove the nd_prefix only when the reference count becomes 0. There's a KAME code implementing this. I'm now porting it, but it'll take some time to check its behavior (a day or two)... Thanks, ---- SUZUKI, Shinsuke @ KAME Project From owner-freebsd-net@FreeBSD.ORG Sat Oct 29 16:32:35 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 225DA16A41F for ; Sat, 29 Oct 2005 16:32:35 +0000 (GMT) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from mail1.cil.se (mail1.cil.se [217.197.56.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8683A43D49 for ; Sat, 29 Oct 2005 16:32:33 +0000 (GMT) (envelope-from jon.otterholm@ide.resurscentrum.se) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Sat, 29 Oct 2005 18:32:31 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: if_bridge and vlan thread-index: AcXcplwfhZk498dsTr6/dwG+3egoIg== From: "Jon Otterholm" To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: if_bridge and vlan 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, 29 Oct 2005 16:32:35 -0000 Hi. Does anyone know if if_bridge supports vlan-interfaces? /Jon From owner-freebsd-net@FreeBSD.ORG Sat Oct 29 18:01: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 CFFB916A421 for ; Sat, 29 Oct 2005 18:01:26 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69D8943D45 for ; Sat, 29 Oct 2005 18:01:26 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 0AA8C1CCDD; Sun, 30 Oct 2005 07:01:25 +1300 (NZDT) Date: Sun, 30 Oct 2005 07:01:25 +1300 From: Andrew Thompson To: Jon Otterholm Message-ID: <20051029180124.GA97835@heff.fud.org.nz> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: if_bridge and vlan 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, 29 Oct 2005 18:01:26 -0000 On Sat, Oct 29, 2005 at 06:32:31PM +0200, Jon Otterholm wrote: > > Hi. > > Does anyone know if if_bridge supports vlan-interfaces? > Yes it does.