From owner-freebsd-net@FreeBSD.ORG Mon Feb 28 04:17:10 2005 Return-Path: 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 C839F16A505; Mon, 28 Feb 2005 04:17:10 +0000 (GMT) Received: from mail.utcorp.net (mail.utcorp.net [146.145.135.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 185AC43D41; Mon, 28 Feb 2005 04:17:10 +0000 (GMT) (envelope-from lister@primetime.com) Received: from [10.200.1.90] (helo=[10.200.1.90]) by mail.utcorp.net with esmtp (Exim 4.30; FreeBSD) id 1D5cha-000CI9-LG; Sun, 27 Feb 2005 23:40:14 -0500 Message-ID: <4222C64D.4050007@primetime.com> Date: Sun, 27 Feb 2005 23:20:45 -0800 From: Lister User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-performance@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Found to be clean Subject: ng_fec and cisco 2931 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 28 Feb 2005 04:17:10 -0000 I have setup ng_fec on a machine with a quad ethernet NIC : de0: port 0xd000-0xd07f mem 0xe3000000-0xe300007f irq 9 at device 4.0 on pci2 de0: Cogent EM440TX 21140A [10-100Mb/s] pass 2.2 de0: address 00:00:d1:1c:c3:a1 de1: port 0xd400-0xd47f mem 0xe3001000-0xe300107f irq 5 at device 5.0 on pci2 de1: Cogent EM440TX 21140A [10-100Mb/s] pass 2.2 de1: address 00:00:d1:1c:c3:a2 de2: port 0xd800-0xd87f mem 0xe3002000-0xe300207f irq 10 at device 6.0 on pci2 de2: Cogent EM440TX 21140A [10-100Mb/s] pass 2.2 de2: address 00:00:d1:1c:c3:a3 de3: port 0xdc00-0xdc7f mem 0xe3003000-0xe300307f irq 11 at device 7.0 on pci2 de3: Cogent EM440TX 21140A [10-100Mb/s] pass 2.2 de3: address 00:00:d1:1c:c3:a4 Commands are : #!/bin/sh ngctl mkpeer fec dummy fec ngctl msg fec0: add_iface "de0" ngctl msg fec0: add_iface "de1" ngctl msg fec0: add_iface "de2" ngctl msg fec0: add_iface "de3" ngctl msg fec0: set_mode_inet ifconfig de0 promisc ifconfig de1 promisc ifconfig de2 promisc ifconfig de3 promisc ifconfig fec0 promisc So, I dhclient fec0 and I have : > ifconfig fec0 fec0: flags=28943 mtu 1500 inet6 fe80::200:d1ff:fe1c:c3a1%fec0 prefixlen 64 scopeid 0xd inet 10.200.1.205 netmask 0xffffff00 broadcast 10.200.1.255 ether 00:00:d1:1c:c3:a1 media: Ethernet none status: active I have all 4 ports connected to the catalyst. From what I have read on fast etherchannel in the cisco docs, it is supposed to detect the etherchannel, e.g. no commands at the switch. Lights blink on and off, change color (orange -> green) and it seems to work ... but only on one interface in the bundle. No faster than 80Mb. I have a 1000Mb intel card in the 2nd test machine that does run much faster than 100. So, is there something I have done wrong, or what? What should I expect to get from 4 x 100 Mb ports? From owner-freebsd-net@FreeBSD.ORG Mon Feb 28 09:26:00 2005 Return-Path: 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 0191016A4CE for ; Mon, 28 Feb 2005 09:26:00 +0000 (GMT) Received: from smtp02.net-yan.com (smtp02.hgcbroadband.com [210.0.255.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10EC043D48 for ; Mon, 28 Feb 2005 09:25:59 +0000 (GMT) (envelope-from sam.wun@authtec.com) Received: (qmail 90925 invoked from network); 28 Feb 2005 09:25:58 -0000 Received: from unknown (HELO [192.168.4.20]) (samwun@hgcbroadband.com@[221.127.238.154]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 28 Feb 2005 09:25:58 -0000 Message-ID: <4222E413.2060807@authtec.com> Date: Mon, 28 Feb 2005 17:27:47 +0800 From: sam wun User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 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: vrrp ip is not reachable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 28 Feb 2005 09:26:00 -0000 Hi list, I have just installed freevrrp in FreeBSD5.4 (pre-release) with the following setup: #public-facing VRID [VRID] serverid = 1 interface = fxp0 priority = 255 addr = 198.168.4.1/32 #password = vrid1 #vridsdep = 2 # backend VRID [VRID] serverid = 1 interface = em0 priority = 255 addr = 192.168.1.1/32 #password = vrid2 #vridsdep = 1 However, the virtual IP 192.168.4.1 (on fxp0) is not reachable with ping, while another virtual IP 192.168.1.1 (on em0) is fine. Here is the result from ifconfig: # ifconfig em0: flags=8843 mtu 1500 options=b inet 192.168.1.253 netmask 0xffffff00 broadcast 192.168.1.255 inet6 fe80::20e:cff:fe05:8229%em0 prefixlen 64 scopeid 0x1 inet 192.168.1.1 netmask 0xffffffff broadcast 192.168.1.1 ether 00:00:5e:00:01:01 media: Ethernet autoselect (100baseTX ) status: active fxp0: flags=8843 mtu 1500 options=8 inet 192.168.4.253 netmask 0xffffff00 broadcast 192.168.4.255 inet6 fe80::211:11ff:fe0f:9543%fxp0 prefixlen 64 scopeid 0x2 inet 192.168.4.2 netmask 0xffffff00 broadcast 192.168.4.255 inet 198.168.4.1 netmask 0xffffff00 broadcast 198.168.4.255 ether 00:00:5e:00:01:01 media: Ethernet autoselect (100baseTX ) status: active plip0: flags=108810 mtu 1500 lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 pfsync0: flags=41 mtu 2020 pflog0: flags=41 mtu 33208 in /etc/rc.conf: gateway_enable="yes" defaultrouter="192.168.4.254" hostname="gateway.home.com" ifconfig_fxp0="inet 192.168.4.253 netmask 255.255.255.0" ifconfig_fxp0_alias0="inet 192.168.4.2 netmask 255.255.255.0" ifconfig_em0="inet 192.168.1.253 netmask 255.255.255.0" result from netstat -rn: Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.4.254 UGS 0 0 fxp0 127.0.0.1 127.0.0.1 UH 0 60 lo0 192.168.1 link#1 UC 0 0 em0 192.168.1.1/32 link#1 UC 0 0 em0 192.168.4 link#2 UC 0 0 fxp0 192.168.4.2 00:00:5e:00:01:01 UHLW 0 6 lo0 192.168.4.254 00:02:b3:0b:3c:d1 UHLW 0 257 fxp0 606 198.168.4 link#2 UC 0 0 fxp0 What should I do to make virtual address 192.168.4.1 reachable from local and external ping? Thanks Sam. From owner-freebsd-net@FreeBSD.ORG Mon Feb 28 11:01:56 2005 Return-Path: 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 D689A16A4CF for ; Mon, 28 Feb 2005 11:01:56 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A51BF43D62 for ; Mon, 28 Feb 2005 11:01:56 +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.1/8.13.1) with ESMTP id j1SB1uAW006697 for ; Mon, 28 Feb 2005 11:01:56 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1SB1tHF006691 for freebsd-net@freebsd.org; Mon, 28 Feb 2005 11:01:55 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 28 Feb 2005 11:01:55 GMT Message-Id: <200502281101.j1SB1tHF006691@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 Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 28 Feb 2005 11:01:57 -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 Feb 28 11:21:40 2005 Return-Path: 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 2F92916A4CE for ; Mon, 28 Feb 2005 11:21:40 +0000 (GMT) Received: from muheleja.eenet.ee (muheleja.eenet.ee [193.40.0.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC5A843D39 for ; Mon, 28 Feb 2005 11:21:38 +0000 (GMT) (envelope-from urmas.lett@eenet.ee) Received: from localhost (localhost [127.0.0.1]) by localhost.eenet.ee (Postfix) with ESMTP id 49E034742B for ; Mon, 28 Feb 2005 13:21:37 +0200 (EET) Received: from muheleja.eenet.ee ([127.0.0.1]) by localhost (muheleja.eenet.ee [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08849-02 for ; Mon, 28 Feb 2005 13:21:37 +0200 (EET) Received: from PORISEJA.eenet.ee (poriseja.eenet.ee [193.40.0.223]) by muheleja.eenet.ee (Postfix) with ESMTP id C538747428 for ; Mon, 28 Feb 2005 13:21:36 +0200 (EET) Message-Id: <6.1.2.0.2.20050228131836.01ba4280@muheleja.eenet.ee> X-Sender: pikk@muheleja.eenet.ee (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 28 Feb 2005 13:21:37 +0200 To: freebsd-net@freebsd.org From: Urmas Lett Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new at eenet.ee Subject: kern.hz and single tcp connection throughput X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 28 Feb 2005 11:21:40 -0000 Hello, I was playing with iperf over ~500km empty gigabit link. FreeBSD 5.3-STABLE kern.hz="100" (default) root@test2:~# iperf -c x.x.x.x ------------------------------------------------------------ Client connecting to x.x.x.x, TCP port 5001 TCP window size: 32.5 KByte (default) ------------------------------------------------------------ [ 3] local y.y.y.y port 56931 connected with x.x.x.x port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 28.8 MBytes 24.1 Mbits/sec root@test2:~# iperf -c x.x.x.x -w 64k ------------------------------------------------------------ Client connecting to x.x.x.x, TCP port 5001 TCP window size: 65.0 KByte (WARNING: requested 64.0 KByte) ------------------------------------------------------------ [ 3] local y.y.y.y port 57926 connected with x.x.x.x port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 28.3 MBytes 23.6 Mbits/sec root@test2:~# iperf -c x.x.x.x -w 128k ------------------------------------------------------------ Client connecting to x.x.x.x, TCP port 5001 TCP window size: 129 KByte (WARNING: requested 128 KByte) ------------------------------------------------------------ [ 3] local y.y.y.y port 64330 connected with x.x.x.x port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 29.0 MBytes 24.2 Mbits/sec root@test2:~# iperf -c x.x.x.x -w 256k ------------------------------------------------------------ Client connecting to x.x.x.x, TCP port 5001 TCP window size: 257 KByte (WARNING: requested 256 KByte) ------------------------------------------------------------ [ 3] local y.y.y.y port 55575 connected with x.x.x.x port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.1 sec 31.2 MBytes 26.0 Mbits/sec root@test2:~# iperf -c x.x.x.x -w 512k ------------------------------------------------------------ Client connecting to x.x.x.x, TCP port 5001 TCP window size: 513 KByte (WARNING: requested 512 KByte) ------------------------------------------------------------ [ 3] local y.y.y.y port 59043 connected with x.x.x.x port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.2 sec 30.0 MBytes 24.7 Mbits/sec ============================================================ kern.hz="1000" root@test2:~# iperf -c x.x.x.x ------------------------------------------------------------ Client connecting to x.x.x.x, TCP port 5001 TCP window size: 32.5 KByte (default) ------------------------------------------------------------ [ 3] local y.y.y.y port 61402 connected with x.x.x.x port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 44.5 MBytes 37.3 Mbits/sec root@test2:~# iperf -c x.x.x.x -w 64k ------------------------------------------------------------ Client connecting to x.x.x.x, TCP port 5001 TCP window size: 65.0 KByte (WARNING: requested 64.0 KByte) ------------------------------------------------------------ [ 3] local y.y.y.y port 62718 connected with x.x.x.x port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 87.9 MBytes 73.7 Mbits/sec root@test2:~# iperf -c x.x.x.x -w 128k ------------------------------------------------------------ Client connecting to x.x.x.x, TCP port 5001 TCP window size: 129 KByte (WARNING: requested 128 KByte) ------------------------------------------------------------ [ 3] local y.y.y.y port 50571 connected with x.x.x.x port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 169 MBytes 142 Mbits/sec root@test2:~# iperf -c x.x.x.x -w 256k ------------------------------------------------------------ Client connecting to x.x.x.x, TCP port 5001 TCP window size: 257 KByte (WARNING: requested 256 KByte) ------------------------------------------------------------ [ 3] local y.y.y.y port 61072 connected with x.x.x.x port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 305 MBytes 255 Mbits/sec root@test2:~# iperf -c x.x.x.x -w 512k ------------------------------------------------------------ Client connecting to x.x.x.x, TCP port 5001 TCP window size: 513 KByte (WARNING: requested 512 KByte) ------------------------------------------------------------ [ 3] local y.y.y.y port 62887 connected with x.x.x.x port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.5 sec 451 MBytes 362 Mbits/sec From owner-freebsd-net@FreeBSD.ORG Mon Feb 28 12:27:02 2005 Return-Path: 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 47E7016A4CE for ; Mon, 28 Feb 2005 12:27:02 +0000 (GMT) Received: from smtp02.net-yan.com (smtp02.hgcbroadband.com [210.0.255.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2845543D46 for ; Mon, 28 Feb 2005 12:27:01 +0000 (GMT) (envelope-from sam.wun@authtec.com) Received: (qmail 76311 invoked from network); 28 Feb 2005 12:26:59 -0000 Received: from unknown (HELO [192.168.4.20]) (samwun@hgcbroadband.com@[221.127.238.154]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 28 Feb 2005 12:26:59 -0000 Message-ID: <42230E80.40509@authtec.com> Date: Mon, 28 Feb 2005 20:28:48 +0800 From: sam wun User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: ping: sendto: Host is down on vrrp IP. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 28 Feb 2005 12:27:02 -0000 Hi list, I don't know what is wrong with the freevrrp setup in my FreeBSD 5.4. After setup and started freevrrpd, I tried to ping both interfaces in localhost, only one interface appeared responsed to the icmp echo request packets, the interface associated with ip 192.168.1.1 is down; while 192.168.4.1 is fine. Both IP addresses are assigned by freevrrpd daemon. # ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 data bytes ping: sendto: Host is down ^C --- 192.168.1.1 ping statistics --- 7 packets transmitted, 0 packets received, 100% packet loss root@gateway [8:20pm] [...local/etc]# ping 192.168.4.1 PING 192.168.4.1 (192.168.4.1): 56 data bytes 64 bytes from 192.168.4.1: icmp_seq=0 ttl=64 time=0.173 ms 64 bytes from 192.168.4.1: icmp_seq=1 ttl=64 time=0.100 ms ^C --- 192.168.4.1 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.100/0.137/0.173/0.036 ms Can anyone please help? Thanks Sam From owner-freebsd-net@FreeBSD.ORG Mon Feb 28 16:11:28 2005 Return-Path: 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 2834416A4CE; Mon, 28 Feb 2005 16:11:28 +0000 (GMT) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3DDD43D48; Mon, 28 Feb 2005 16:11:27 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id DAB5AF222; Mon, 28 Feb 2005 11:11:26 -0500 (EST) Received: by canoe.dclg.ca (Postfix, from userid 101) id B2FB34662; Mon, 28 Feb 2005 11:11:25 -0500 (EST) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16931.17069.667570.224967@canoe.dclg.ca> Date: Mon, 28 Feb 2005 11:11:25 -0500 To: Lister In-Reply-To: <4222C64D.4050007@primetime.com> References: <4222C64D.4050007@primetime.com> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid cc: freebsd-net@freebsd.org cc: freebsd-performance@freebsd.org Subject: ng_fec and cisco 2931 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 28 Feb 2005 16:11:28 -0000 >>>>> "lister" == lister writes: lister> I have setup ng_fec on a machine with a quad ethernet NIC : lister> de0: port 0xd000-0xd07f mem Our own testing with this card (not using fec ... just traffic on the 4 ports) has determined that it appears to have a 100 megabit limit to the total of 4 ports on the card. Now... this could be a FreeBSD driver issue ... or a PCI bus issue, but in all our tests with several motherboards and many versions of FreeBSD (from 3.2 or so through about 4.5) we were never able to achieve more than 100 megabit on the card in total. Our application was an NFS server that had 100's of diskless nodes running from it. We suspected that this could be some interaction between the speed of the disks (and their pci cost) and the card, so we isolated the card by doing straight packet tests (no meaningful data) and still found the card maxxing out at 100 megabit total over the 4 ports. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-net@FreeBSD.ORG Mon Feb 28 21:44:05 2005 Return-Path: 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 3005D16A4CE; Mon, 28 Feb 2005 21:44:05 +0000 (GMT) Received: from kalypso.opteqint.net (kalypso.opteqint.net [160.124.112.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DBC843D49; Mon, 28 Feb 2005 21:44:02 +0000 (GMT) (envelope-from cole@opteqint.net) Received: from c1-5-rrba.isadsl.co.za ([196.34.192.5] helo=deadmind) by kalypso.opteqint.net with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43 (FreeBSD)) id 1D5sgG-000OkO-40; Mon, 28 Feb 2005 23:44:00 +0200 Message-ID: <003101c51ddf$347fa420$4206000a@deadmind> From: "Cole" To: Date: Mon, 28 Feb 2005 23:48:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: -97.5 (---------------------------------------------------) X-Spam-Report: Spam detection software, running on the system "kalypso.opteqint.net", hasmessagelabel similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hey. I have a Freebsd server runningthen had no problems what so ever building ntop, except for the xml plugin though I have libxml installed, and specified the right paths to the .h. But that is not the problem. Ntop runs and works fine on this box, not a single problem that I can see. [...] Content analysis details: (-97.5 points, 4.3 required) pts rule name description -------------------------------------------------- -100 USER_IN_WHITELIST From: address is in the user's white-list 2.5 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL [196.34.192.5 listed in sbl-xbl.spamhaus.org] cc: freebsd-net@freebsd.org Subject: Dynamically Linked Library Problem (maybe) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Cole List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 21:44:05 -0000 Hey. I have a Freebsd server running freebsd-4.9-stable. I cvsupped the ntop src last week for 3.1.1. I then had no problems what so ever building ntop, except for the xml plugin saying it was not built, cause it cannot find xmlversion.h, even though I have libxml installed, and specified the right paths to the .h. But that is not the problem. Ntop runs and works fine on this box, not a single problem that I can see. The problem is that, I have a few other servers, that I want to copy ntop too, but dont want to build it on all those boxes. I created a tar with all the ntop binaries, as well as all the libraries that its linked too, as well as all the plugins that ntop uses from both the /usr/local/lib directory as well as the plugins from the /usr/local/lib/ntop/plugins directory. I rebuilt all the symbolic links for all the libraries and plugins and all the files that ntop was linked too. I have also checked all the permissions on all the files and they are all the same. One other thing, the boxes that I am copying ntop to, are almost exact duplicates of the first box that I built ntop on, and where it works fine. The problem is, when running ntop on the boxes that I copied it to, after checking all the permissions and links and everything, I get these errors with regards to the plugins. Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/icmpPlugin.so' entry function [Invalid shared object handle 0x29a14000] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/snmpPlugin.so' entry function [Invalid shared object handle 0x29a16400] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/sflowPlugin.so' entry function [Invalid shared object handle 0x29a19800] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/rrdPlugin.so' entry function [Invalid shared object handle 0x29a1bc00] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/pdaPlugin.so' entry function [Invalid shared object handle 0x2bcae400] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/netflowPlugin.so' entry function [Invalid shared object handle 0x2d862800] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/lastSeenPlugin.so' entry function [Invalid shared object handle 0x2d866c00] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/xmldumpPlugin.so' entry function [Invalid shared object handle 0x2f697000] I have absolutely no idea how this has happened, and I have had this problem before, and not a single other person was able to help me in any regards what so ever. I was hoping maybe someone would at least know what this error even means, so that I have some idea of what I am meant to be doing to fix this. If anyone has any idea, I would gladly apprecaite any suggestions. Thanks /Cole From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 00:04:38 2005 Return-Path: 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 9DB9516A4CE; Tue, 1 Mar 2005 00:04:38 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4877E43D55; Tue, 1 Mar 2005 00:04:38 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C14D1512A7; Mon, 28 Feb 2005 16:04:36 -0800 (PST) Date: Mon, 28 Feb 2005 16:04:36 -0800 From: Kris Kennaway To: net@FreeBSD.org Message-ID: <20050301000436.GA33346@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i cc: rwatson@FreeBSD.org cc: sparc64@FreeBSD.org Subject: Race condition in mb_free_ext()? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 01 Mar 2005 00:04:38 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'm seeing an easily-provoked livelock on quad-CPU sparc64 machines running RELENG_5. It's hard to get a good trace because the processes running on other CPUs cannot be traced from DDB, but I've been lucky a few times: db> show alllocks Process 15 (swi1: net) thread 0xfffff8001fb07480 (100008) exclusive sleep mutex so_snd r = 0 (0xfffff800178432a8) locked @ netinet/tcp_input.c:2189 exclusive sleep mutex inp (tcpinp) r = 0 (0xfffff800155c3b08) locked @ netinet/tcp_input.c:744 exclusive sleep mutex tcp r = 0 (0xc0bdf788) locked @ netinet/tcp_input.c:617 db> wh 15 Tracing pid 15 tid 100008 td 0xfffff8001fb07480 sab_intr() at sab_intr+0x40 psycho_intr_stub() at psycho_intr_stub+0x8 intr_fast() at intr_fast+0x88 -- interrupt level=0xd pil=0 %o7=0xc01a0040 -- mb_free_ext() at mb_free_ext+0x28 sbdrop_locked() at sbdrop_locked+0x19c tcp_input() at tcp_input+0x2aa0 ip_input() at ip_input+0x964 netisr_processqueue() at netisr_processqueue+0x7c swi_net() at swi_net+0x120 ithread_loop() at ithread_loop+0x24c fork_exit() at fork_exit+0xd4 fork_trampoline() at fork_trampoline+0x8 db> That code is here in mb_free_ext(): /* * This is tricky. We need to make sure to decrement the * refcount in a safe way but to also clean up if we're the * last reference. This method seems to do it without race. */ while (dofree == 0) { cnt = *(m->m_ext.ref_cnt); if (atomic_cmpset_int(m->m_ext.ref_cnt, cnt, cnt - 1)) { if (cnt == 1) dofree = 1; break; } } mb_free_ext+0x24: casa 0x4 , %g2, %g1 mb_free_ext+0x28: subcc %g1, %g2, %g0 which is inside the atomic_cmpset_int (i.e. it's probably spinning in the loop). Can anyone see if there's a problem with this code, or perhaps the sparc64 implementation of atomic_cmpset_int()? Kris --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCI7GUWry0BWjoQKURAlD7AJ972l7rDX+G0cG95Iv2pqEVRINnrQCdHQeP fItGM33s+lUrRQehQkKJx8I= =TG2u -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 06:00:39 2005 Return-Path: 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 1411916A4D2; Tue, 1 Mar 2005 06:00:39 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC36043D69; Tue, 1 Mar 2005 06:00:25 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id C939872DD4; Mon, 28 Feb 2005 22:00:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id C6C5B72DCB; Mon, 28 Feb 2005 22:00:25 -0800 (PST) Date: Mon, 28 Feb 2005 22:00:25 -0800 (PST) From: Doug White To: Kris Kennaway In-Reply-To: <20050301000436.GA33346@xor.obsecurity.org> Message-ID: <20050228214850.X62607@carver.gumbysoft.com> References: <20050301000436.GA33346@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: sparc64@FreeBSD.org cc: rwatson@FreeBSD.org cc: net@FreeBSD.org Subject: Re: Race condition in mb_free_ext()? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 01 Mar 2005 06:00:39 -0000 Since we're moving the conversation on this over here.... On Mon, 28 Feb 2005, Kris Kennaway wrote: > I'm seeing an easily-provoked livelock on quad-CPU sparc64 machines > running RELENG_5. It's hard to get a good trace because the processes > running on other CPUs cannot be traced from DDB, but I've been lucky a > few times: > > db> show alllocks > Process 15 (swi1: net) thread 0xfffff8001fb07480 (100008) > exclusive sleep mutex so_snd r = 0 (0xfffff800178432a8) locked @ netinet/tcp_input.c:2189 > exclusive sleep mutex inp (tcpinp) r = 0 (0xfffff800155c3b08) locked @ netinet/tcp_input.c:744 > exclusive sleep mutex tcp r = 0 (0xc0bdf788) locked @ netinet/tcp_input.c:617 > db> wh 15 > Tracing pid 15 tid 100008 td 0xfffff8001fb07480 > sab_intr() at sab_intr+0x40 > psycho_intr_stub() at psycho_intr_stub+0x8 > intr_fast() at intr_fast+0x88 > -- interrupt level=0xd pil=0 %o7=0xc01a0040 -- > mb_free_ext() at mb_free_ext+0x28 > sbdrop_locked() at sbdrop_locked+0x19c > tcp_input() at tcp_input+0x2aa0 > ip_input() at ip_input+0x964 > netisr_processqueue() at netisr_processqueue+0x7c > swi_net() at swi_net+0x120 > ithread_loop() at ithread_loop+0x24c > fork_exit() at fork_exit+0xd4 > fork_trampoline() at fork_trampoline+0x8 > db> > > That code is here in mb_free_ext(): > > /* > * This is tricky. We need to make sure to decrement the > * refcount in a safe way but to also clean up if we're the > * last reference. This method seems to do it without race. > */ > while (dofree == 0) { > cnt = *(m->m_ext.ref_cnt); > if (atomic_cmpset_int(m->m_ext.ref_cnt, cnt, cnt - 1)) { > if (cnt == 1) > dofree = 1; > break; > } > } > > mb_free_ext+0x24: casa 0x4 , %g2, %g1 > mb_free_ext+0x28: subcc %g1, %g2, %g0 > > which is inside the atomic_cmpset_int (i.e. it's probably spinning in > the loop). > > Can anyone see if there's a problem with this code, or perhaps the > sparc64 implementation of atomic_cmpset_int()? I considered earlier today changing cnt to be a u_int volitile* to match how ipi_wait() does a poll on the cpumask that other CPUs are updating. (alc@ had flagged this earlier on in our debugging.) The volitile marker forces some extra load instructions to ensure both the pointer and the value its pointing to stay fresh. rwatson convinced me to wait and never got back to me though :-) He also suggested putting a loop counter in and perhaps a KASSERT to make sure ref_cnt isn't some absurdly large value (like 0xdeadc0de). Forgive me for being naieve, but is there a reason you don't do an atomic subtraction on the refcount? I can see why it repeats -- if two things are warring over the refcount one or the other keep trying until one wins -- but the subtraction would seem more intuitive. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 12:01:47 2005 Return-Path: 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 0DB8C16A4CE; Tue, 1 Mar 2005 12:01:47 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE2E343D1F; Tue, 1 Mar 2005 12:01:46 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 5A83D46B0C; Tue, 1 Mar 2005 07:01:46 -0500 (EST) Date: Tue, 1 Mar 2005 11:59:49 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Doug White In-Reply-To: <20050228214850.X62607@carver.gumbysoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: sparc64@FreeBSD.org cc: net@FreeBSD.org cc: Kris Kennaway Subject: Re: Race condition in mb_free_ext()? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 01 Mar 2005 12:01:47 -0000 On Mon, 28 Feb 2005, Doug White wrote: > Forgive me for being naieve, but is there a reason you don't do an > atomic subtraction on the refcount? I can see why it repeats -- if two > things are warring over the refcount one or the other keep trying until > one wins -- but the subtraction would seem more intuitive. I'm not all that familiar with this code, but my guess is that he uses the cmpset so that he guarantees the value of 'cnt' is fresh with respect to the decrement -- i.e., only one caller to mb_free_ext() will end up with a 'cnt' of 1 and perform the GC. If you re-read it, there may be a race. Robert N M Watson From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 14:22:44 2005 Return-Path: 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 7E20416A4DB for ; Tue, 1 Mar 2005 14:22:44 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8C8543D2F for ; Tue, 1 Mar 2005 14:22:43 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (root@cell.sick.ru [217.72.144.68]) by relay.bestcom.ru (8.13.1/8.12.9) with ESMTP id j21EMf5h078876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Mar 2005 17:22:42 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.1/8.12.8) with ESMTP id j21EMfeu080017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Mar 2005 17:22:41 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.1/8.13.1/Submit) id j21EMZ9j080011; Tue, 1 Mar 2005 17:22:36 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 1 Mar 2005 17:22:35 +0300 From: Gleb Smirnoff To: Arnold Lee Message-ID: <20050301142235.GB79825@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Arnold Lee , freebsd-net@freebsd.org References: <20050224150649.9076.qmail@web15801.mail.cnb.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20050224150649.9076.qmail@web15801.mail.cnb.yahoo.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version devel-20050125, clamav-milter version 0.80ff on relay.bestcom.ru X-Virus-Status: Clean cc: freebsd-net@FreeBSD.org Subject: Re: a problem with netgraph X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 01 Mar 2005 14:22:44 -0000 On Thu, Feb 24, 2005 at 11:06:49PM +0800, Arnold Lee wrote: A> I use Freebsd 5.3 + mpd 3.18, and I wanna create more than 500 netgraph nodes of ng_pppoe type using mpd. But mpd can only create 100 nodes! Who set this limit? mpd or netgraph system? and how to break it? Bye the way, freebsd 4.9 + mpd 3.18 are the same. Possibly names of resulting nodes are too long. Try shorter names for bundles and links. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 20:47:36 2005 Return-Path: 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 77DF416A4CE for ; Tue, 1 Mar 2005 20:47:36 +0000 (GMT) Received: from mail24.sea5.speakeasy.net (mail24.sea5.speakeasy.net [69.17.117.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DE3843D46 for ; Tue, 1 Mar 2005 20:47:35 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 11895 invoked from network); 1 Mar 2005 20:47:35 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 1 Mar 2005 20:47:34 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j21KlPbX074756; Tue, 1 Mar 2005 15:47:29 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-sparc64@FreeBSD.org Date: Tue, 1 Mar 2005 13:40:18 -0500 User-Agent: KMail/1.6.2 References: <20050301000436.GA33346@xor.obsecurity.org> In-Reply-To: <20050301000436.GA33346@xor.obsecurity.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503011340.18162.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: net@FreeBSD.org cc: rwatson@FreeBSD.org cc: bmilekic@FreeBSD.org cc: sparc64@FreeBSD.org cc: Kris Kennaway Subject: Re: Race condition in mb_free_ext()? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 01 Mar 2005 20:47:36 -0000 On Monday 28 February 2005 07:04 pm, Kris Kennaway wrote: > I'm seeing an easily-provoked livelock on quad-CPU sparc64 machines > running RELENG_5. It's hard to get a good trace because the processes > running on other CPUs cannot be traced from DDB, but I've been lucky a > few times: > > db> show alllocks > Process 15 (swi1: net) thread 0xfffff8001fb07480 (100008) > exclusive sleep mutex so_snd r = 0 (0xfffff800178432a8) locked @ > netinet/tcp_input.c:2189 exclusive sleep mutex inp (tcpinp) r = 0 > (0xfffff800155c3b08) locked @ netinet/tcp_input.c:744 exclusive sleep mutex > tcp r = 0 (0xc0bdf788) locked @ netinet/tcp_input.c:617 db> wh 15 > Tracing pid 15 tid 100008 td 0xfffff8001fb07480 > sab_intr() at sab_intr+0x40 > psycho_intr_stub() at psycho_intr_stub+0x8 > intr_fast() at intr_fast+0x88 > -- interrupt level=0xd pil=0 %o7=0xc01a0040 -- > mb_free_ext() at mb_free_ext+0x28 > sbdrop_locked() at sbdrop_locked+0x19c > tcp_input() at tcp_input+0x2aa0 > ip_input() at ip_input+0x964 > netisr_processqueue() at netisr_processqueue+0x7c > swi_net() at swi_net+0x120 > ithread_loop() at ithread_loop+0x24c > fork_exit() at fork_exit+0xd4 > fork_trampoline() at fork_trampoline+0x8 > db> > > That code is here in mb_free_ext(): > > /* > * This is tricky. We need to make sure to decrement the > * refcount in a safe way but to also clean up if we're the > * last reference. This method seems to do it without race. > */ > while (dofree == 0) { > cnt = *(m->m_ext.ref_cnt); > if (atomic_cmpset_int(m->m_ext.ref_cnt, cnt, cnt - 1)) { > if (cnt == 1) > dofree = 1; > break; > } > } Well, this is obtuse at least. A simpler version would be: do { cnt = *m->m_ext.ref_cnt; } while (atomic_cmpset_int(m->m_ext.ref_cnt, cnt, cnt - 1) == 0); dofree = (cnt == 1); -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 23:04:29 2005 Return-Path: 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 E184716A4CE for ; Tue, 1 Mar 2005 23:04:29 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48E4543D1D for ; Tue, 1 Mar 2005 23:04:28 +0000 (GMT) (envelope-from bosko.milekic@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2439455wra for ; Tue, 01 Mar 2005 15:04:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=dZeLE31ZQy9p686MrwZ5ROAAUahNPUv/f4QmtSJXUWHOIIaIC1gMoAaWpzGqa484CPCW3SijDH7yQ+Pl4YtPHQDcNa/UpBxAkQS1dcyKEYCtCu78IyBEC1U+XE7qorrte//dal8Zc9K2ek9zNmLncT/Kw9klvao4r351Hc/NB4Y= Received: by 10.54.18.62 with SMTP id 62mr85204wrr; Tue, 01 Mar 2005 15:04:27 -0800 (PST) Received: by 10.54.24.41 with HTTP; Tue, 1 Mar 2005 15:04:27 -0800 (PST) Message-ID: Date: Tue, 1 Mar 2005 18:04:27 -0500 From: Bosko Milekic To: John Baldwin In-Reply-To: <200503011340.18162.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050301000436.GA33346@xor.obsecurity.org> <200503011340.18162.jhb@FreeBSD.org> cc: Kris Kennaway cc: net@freebsd.org cc: rwatson@freebsd.org cc: bmilekic@freebsd.org cc: sparc64@freebsd.org cc: freebsd-sparc64@freebsd.org Subject: Re: Race condition in mb_free_ext()? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Bosko Milekic List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 23:04:30 -0000 On Tue, 1 Mar 2005 13:40:18 -0500, John Baldwin wrote: > On Monday 28 February 2005 07:04 pm, Kris Kennaway wrote: > > I'm seeing an easily-provoked livelock on quad-CPU sparc64 machines > > running RELENG_5. It's hard to get a good trace because the processes > > running on other CPUs cannot be traced from DDB, but I've been lucky a > > few times: > > > > db> show alllocks > > Process 15 (swi1: net) thread 0xfffff8001fb07480 (100008) > > exclusive sleep mutex so_snd r = 0 (0xfffff800178432a8) locked @ > > netinet/tcp_input.c:2189 exclusive sleep mutex inp (tcpinp) r = 0 > > (0xfffff800155c3b08) locked @ netinet/tcp_input.c:744 exclusive sleep mutex > > tcp r = 0 (0xc0bdf788) locked @ netinet/tcp_input.c:617 db> wh 15 > > Tracing pid 15 tid 100008 td 0xfffff8001fb07480 > > sab_intr() at sab_intr+0x40 > > psycho_intr_stub() at psycho_intr_stub+0x8 > > intr_fast() at intr_fast+0x88 > > -- interrupt level=0xd pil=0 %o7=0xc01a0040 -- > > mb_free_ext() at mb_free_ext+0x28 > > sbdrop_locked() at sbdrop_locked+0x19c > > tcp_input() at tcp_input+0x2aa0 > > ip_input() at ip_input+0x964 > > netisr_processqueue() at netisr_processqueue+0x7c > > swi_net() at swi_net+0x120 > > ithread_loop() at ithread_loop+0x24c > > fork_exit() at fork_exit+0xd4 > > fork_trampoline() at fork_trampoline+0x8 > > db> > > > > That code is here in mb_free_ext(): > > > > /* > > * This is tricky. We need to make sure to decrement the > > * refcount in a safe way but to also clean up if we're the > > * last reference. This method seems to do it without race. > > */ > > while (dofree == 0) { > > cnt = *(m->m_ext.ref_cnt); > > if (atomic_cmpset_int(m->m_ext.ref_cnt, cnt, cnt - 1)) { > > if (cnt == 1) > > dofree = 1; > > break; > > } > > } > > Well, this is obtuse at least. A simpler version would be: > > do { > cnt = *m->m_ext.ref_cnt; > } while (atomic_cmpset_int(m->m_ext.ref_cnt, cnt, cnt - 1) == 0); > dofree = (cnt == 1); > > -- > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = http://www.FreeBSD.org Your suggestion will always enter the loop and do the atomic regardless of what dofree is set to above that code (not shown in Kris' paste): [...] /* Account for lazy ref count assign. */ if (m->m_ext.ref_cnt == NULL) dofree = 1; else dofree = 0; /* * This is tricky. We need to make sure to decrement the * refcount in a safe way but to also clean up if we're the * last reference. This method seems to do it without race. */ [...] The segment could still be reworked, but anyway: This does not appear to explain the livelock. What's m->m_ext.ref_cnt point to? And what is the value at the location pointed to by m->m_ext.ref_cnt? Regardless, though, the livelock itself, assuming it is due to a long time being spent spinning in the above loop, should not be caused by underruns or overruns of the reference count (those may only cause leaking of the cluster). Furthermore, the above code has been around in that form for some time now and in fact the loop was probably entered *more* often in the past (before the 'dofree' variable was introduced there). Since when are you able to cause the livelock to happen, and are you sure it is the mb_free_ext() that is looping indefinitely? I do not know sparc64 well, but what are the semantics of atomic_cmpset_int()? I see that it is defined to use the 'casa' instruction; does atomic_cmpset_int() behave the same way as it does on i386? -Bosko -- Bosko Milekic - If I were a number, I'd be irrational. Contact Info: http://bmilekic.unixdaemons.com/contact.txt From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 23:10:58 2005 Return-Path: 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 E2E8416A4D2 for ; Tue, 1 Mar 2005 23:10:58 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FC0E43D5E for ; Tue, 1 Mar 2005 23:10:56 +0000 (GMT) (envelope-from bosko.milekic@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2440819wra for ; Tue, 01 Mar 2005 15:10:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=eyLPp9w2OH8MgKXVg+J/qseCC6uWkVFZEuVf5CQyeV/k4MVLb10vpE1DxumhyvcEga25O8Ku3rlA1YKIiyRdnnkKn2uNgO9VrXxLVhogvzZWVtWtBg6TS19zNf1QNspst4Eare/68TyNBLuWAhs59qulbataIEYNZWgtc2E3tf8= Received: by 10.54.10.7 with SMTP id 7mr87677wrj; Tue, 01 Mar 2005 15:10:55 -0800 (PST) Received: by 10.54.24.41 with HTTP; Tue, 1 Mar 2005 15:10:55 -0800 (PST) Message-ID: Date: Tue, 1 Mar 2005 18:10:55 -0500 From: Bosko Milekic To: John Baldwin In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050301000436.GA33346@xor.obsecurity.org> <200503011340.18162.jhb@FreeBSD.org> cc: Kris Kennaway cc: net@freebsd.org cc: rwatson@freebsd.org cc: bmilekic@freebsd.org cc: sparc64@freebsd.org cc: freebsd-sparc64@freebsd.org Subject: Re: Race condition in mb_free_ext()? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Bosko Milekic List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 23:10:59 -0000 P.S.: Not sure if this is related: http://www.mail-archive.com/bk-commits-24@vger.kernel.org/msg00136.html On Tue, 1 Mar 2005 18:04:27 -0500, Bosko Milekic wrote: > On Tue, 1 Mar 2005 13:40:18 -0500, John Baldwin wrote: > > On Monday 28 February 2005 07:04 pm, Kris Kennaway wrote: > > > I'm seeing an easily-provoked livelock on quad-CPU sparc64 machines > > > running RELENG_5. It's hard to get a good trace because the processes > > > running on other CPUs cannot be traced from DDB, but I've been lucky a > > > few times: > > > > > > db> show alllocks > > > Process 15 (swi1: net) thread 0xfffff8001fb07480 (100008) > > > exclusive sleep mutex so_snd r = 0 (0xfffff800178432a8) locked @ > > > netinet/tcp_input.c:2189 exclusive sleep mutex inp (tcpinp) r = 0 > > > (0xfffff800155c3b08) locked @ netinet/tcp_input.c:744 exclusive sleep mutex > > > tcp r = 0 (0xc0bdf788) locked @ netinet/tcp_input.c:617 db> wh 15 > > > Tracing pid 15 tid 100008 td 0xfffff8001fb07480 > > > sab_intr() at sab_intr+0x40 > > > psycho_intr_stub() at psycho_intr_stub+0x8 > > > intr_fast() at intr_fast+0x88 > > > -- interrupt level=0xd pil=0 %o7=0xc01a0040 -- > > > mb_free_ext() at mb_free_ext+0x28 > > > sbdrop_locked() at sbdrop_locked+0x19c > > > tcp_input() at tcp_input+0x2aa0 > > > ip_input() at ip_input+0x964 > > > netisr_processqueue() at netisr_processqueue+0x7c > > > swi_net() at swi_net+0x120 > > > ithread_loop() at ithread_loop+0x24c > > > fork_exit() at fork_exit+0xd4 > > > fork_trampoline() at fork_trampoline+0x8 > > > db> > > > > > > That code is here in mb_free_ext(): > > > > > > /* > > > * This is tricky. We need to make sure to decrement the > > > * refcount in a safe way but to also clean up if we're the > > > * last reference. This method seems to do it without race. > > > */ > > > while (dofree == 0) { > > > cnt = *(m->m_ext.ref_cnt); > > > if (atomic_cmpset_int(m->m_ext.ref_cnt, cnt, cnt - 1)) { > > > if (cnt == 1) > > > dofree = 1; > > > break; > > > } > > > } > > > > Well, this is obtuse at least. A simpler version would be: > > > > do { > > cnt = *m->m_ext.ref_cnt; > > } while (atomic_cmpset_int(m->m_ext.ref_cnt, cnt, cnt - 1) == 0); > > dofree = (cnt == 1); > > > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > > "Power Users Use the Power to Serve" = http://www.FreeBSD.org > > Your suggestion will always enter the loop and do the atomic > regardless of what dofree is set to above that code (not shown in > Kris' paste): > > [...] > /* Account for lazy ref count assign. */ > if (m->m_ext.ref_cnt == NULL) > dofree = 1; > else > dofree = 0; > > /* > * This is tricky. We need to make sure to decrement the > * refcount in a safe way but to also clean up if we're the > * last reference. This method seems to do it without race. > */ > [...] > > The segment could still be reworked, but anyway: > > This does not appear to explain the livelock. What's m->m_ext.ref_cnt > point to? And what is the value at the location pointed to by > m->m_ext.ref_cnt? Regardless, though, the livelock itself, assuming it > is due to a long time being spent spinning in the above loop, should > not be caused by underruns or overruns of the reference count (those > may only cause leaking of the cluster). > > Furthermore, the above code has been around in that form for some time > now and in fact the loop was probably entered *more* often in the past > (before the 'dofree' variable was introduced there). Since when are > you able to cause the livelock to happen, and are you sure it is the > mb_free_ext() that is looping indefinitely? > > I do not know sparc64 well, but what are the semantics of > atomic_cmpset_int()? I see that it is defined to use the 'casa' > instruction; does atomic_cmpset_int() behave the same way as it does > on i386? > > -Bosko > > -- > Bosko Milekic - If I were a number, I'd be irrational. > Contact Info: http://bmilekic.unixdaemons.com/contact.txt > -- Bosko Milekic - If I were a number, I'd be irrational. Contact Info: http://bmilekic.unixdaemons.com/contact.txt From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 23:14:40 2005 Return-Path: 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 D209A16A4CE; Tue, 1 Mar 2005 23:14:40 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 927B843D53; Tue, 1 Mar 2005 23:14:40 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 1C2CC5126E; Tue, 1 Mar 2005 15:14:39 -0800 (PST) Date: Tue, 1 Mar 2005 15:14:38 -0800 From: Kris Kennaway To: Bosko Milekic Message-ID: <20050301231438.GA25573@xor.obsecurity.org> References: <20050301000436.GA33346@xor.obsecurity.org> <200503011340.18162.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: Kris Kennaway cc: John Baldwin cc: net@freebsd.org cc: rwatson@freebsd.org cc: freebsd-sparc64@freebsd.org cc: sparc64@freebsd.org cc: bmilekic@freebsd.org Subject: Re: Race condition in mb_free_ext()? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 01 Mar 2005 23:14:41 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Mar 01, 2005 at 06:04:27PM -0500, Bosko Milekic wrote: > This does not appear to explain the livelock. alc and dwhite tracked it down to a missing volatile causing gcc to mis-optimize the loop: - cnt = *(m->m_ext.ref_cnt); + cnt = *(volatile u_int *)(m->m_ext.ref_cnt); I'm currently testing that. Kris --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD4DBQFCJPdeWry0BWjoQKURAhjEAJQIzH83/FFMg4OTWDMkev19ElbpAKD2mYru pC3bsDMZrisMSEJodagwXw== =WydC -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 23:49:59 2005 Return-Path: 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 B347D16A4CE; Tue, 1 Mar 2005 23:49:59 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 427F843D73; Tue, 1 Mar 2005 23:49:59 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])j21NnbFQ020169; Tue, 1 Mar 2005 18:49:37 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.3/8.12.1/Submit) id j21NnbO9020168; Tue, 1 Mar 2005 18:49:37 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Tue, 1 Mar 2005 18:49:37 -0500 From: Bosko Milekic To: Kris Kennaway Message-ID: <20050301234937.GA19502@technokratis.com> References: <20050301000436.GA33346@xor.obsecurity.org> <200503011340.18162.jhb@FreeBSD.org> <20050301231438.GA25573@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050301231438.GA25573@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i cc: John Baldwin cc: net@freebsd.org cc: rwatson@freebsd.org cc: freebsd-sparc64@freebsd.org cc: sparc64@freebsd.org cc: Bosko Milekic cc: bmilekic@freebsd.org Subject: Re: Race condition in mb_free_ext()? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 01 Mar 2005 23:49:59 -0000 You know, the more and more we run into these problems specific to how reference counting is performed, I keep wondering whether some cleverly defined macros for dealing with common reference counting operations would be worthwhile. I'm not saying "introduce a refcount_t type and a full-blown abstraction," but some template-like stuff might be useful. It took a while just to get the refcount decrement on free path free of races on SMP, and that's only in the mbuf code. -Bosko On Tue, Mar 01, 2005 at 03:14:38PM -0800, Kris Kennaway wrote: > On Tue, Mar 01, 2005 at 06:04:27PM -0500, Bosko Milekic wrote: > > > This does not appear to explain the livelock. > > alc and dwhite tracked it down to a missing volatile causing gcc to > mis-optimize the loop: > > - cnt = *(m->m_ext.ref_cnt); > + cnt = *(volatile u_int *)(m->m_ext.ref_cnt); > > I'm currently testing that. > > Kris -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Tue Mar 1 23:53:25 2005 Return-Path: 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 009A816A4CE; Tue, 1 Mar 2005 23:53:25 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0E6243D58; Tue, 1 Mar 2005 23:53:24 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])j21NrL4c020888; Tue, 1 Mar 2005 18:53:21 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.3/8.12.1/Submit) id j21NrLvm020887; Tue, 1 Mar 2005 18:53:21 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Tue, 1 Mar 2005 18:53:21 -0500 From: Bosko Milekic To: Doug White Message-ID: <20050301235321.GA20232@technokratis.com> References: <20050301000436.GA33346@xor.obsecurity.org> <20050228214850.X62607@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050228214850.X62607@carver.gumbysoft.com> User-Agent: Mutt/1.4.2.1i cc: sparc64@FreeBSD.org cc: rwatson@FreeBSD.org cc: net@FreeBSD.org cc: Kris Kennaway Subject: Re: Race condition in mb_free_ext()? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 01 Mar 2005 23:53:25 -0000 On Mon, Feb 28, 2005 at 10:00:25PM -0800, Doug White wrote: > Forgive me for being naieve, but is there a reason you don't do an atomic > subtraction on the refcount? I can see why it repeats -- if two things > are warring over the refcount one or the other keep trying until one wins > -- but the subtraction would seem more intuitive. The subtraction is atomic and is part of the cmpset. If you were to only do a subtraction, you risk racing on figuring out what the counter value before the subtraction was and making sure that it stays consistent after the subtraction. That is the purpose of the cmpset. The idea is that only the LAST thread to decrement the counter down to exactly 1 frees the cluster. If you look at the CVS history for that routine and its various incarnations (you might need to look at kern/subr_mbuf.c in the attic, since mb_free_ext() used to be there, iirc), you will see various points in time where we had this wrong. > -- > Doug White | FreeBSD: The Power to Serve > dwhite@gumbysoft.com | www.FreeBSD.org -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 00:29:53 2005 Return-Path: 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 1EB6F16A4CE; Wed, 2 Mar 2005 00:29:53 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCFEC43D39; Wed, 2 Mar 2005 00:29:52 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.8) with ESMTP id j220TqOL064350; Tue, 1 Mar 2005 16:29:52 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j220TnBc064349; Tue, 1 Mar 2005 16:29:49 -0800 (PST) (envelope-from rizzo) Date: Tue, 1 Mar 2005 16:29:49 -0800 From: Luigi Rizzo To: John Baldwin Message-ID: <20050301162949.A64187@xorpc.icir.org> References: <20050217161031.A46700@xorpc.icir.org> <200503011642.48813.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200503011642.48813.jhb@FreeBSD.org>; from jhb@FreeBSD.org on Tue, Mar 01, 2005 at 04:42:48PM -0500 cc: dima <_pppp@mail.ru> cc: net@FreeBSD.org Subject: Re: Giant-free polling [PATCH] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Mar 2005 00:29:53 -0000 [cc-ing net@freebsd.org to get more opinions] On Tue, Mar 01, 2005 at 04:42:48PM -0500, John Baldwin wrote: > On Thursday 17 February 2005 07:10 pm, Luigi Rizzo wrote: > > i am no expert about the locking but i see places where > > you grab polling_lock followed by ifnet_lock, and others where > > you use the opposite order. This seems prone to deadlock... > > Yes, it basically seems that the polling_lock should be removed and just the > ifnet_lock used because the the ifnet_lock is already always held when the > polling_lock is locked. this said, if the lock requests are blocking, you basically end up with the polling loops always contending for the locks, with only one doing actual work and the other one always busy-waiting. Assuming the primitive exists, I think the correct way to implement SMP polling is to use non-blocking locks, something like this (in pseudocode) poll_loop() { have_polling_lock = try_get_lock(polling_lock) foreach(ifp in polled_interfaces) { if (have_polling_lock) have_ifp_lock = get_lock(ifp) // returns true else have_ifp_lock = try_get_lock(ifp) if (have_ifp_lock) { ifp->poll(); release_lock(ifp) } } if (have_polling_lock) release_lock(polling_lock); } so additional polling processes after the first one will not block on busy interfaces and move forward instead. This should remove a bit of contention, and let separate processes actually work on different interfaces. cheers luigi > > On Thu, Feb 17, 2005 at 06:18:07PM +0300, dima wrote: > > > I have removed Giant lock from the kern_poll.c. It is actually replaced > > > with a pair of ifnet_lock and polling_lock (added by me). The ifnet_lock > > > is needed considering the situation when a device is dettached during the > > > polling cycle. I successuflly tested it on 5.3-RELEASE-p5 i386/UP with > > > fxp NIC and going to test i386/SMP with 2 em NICs next weekend (the SMP > > > #error can also be removed I think). There is still a problem with the > > > patch since mtx_destroy() for polling_lock is not called. > > > > > > Please review the patch and tell me what you think about it. > > -- > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 02:07:57 2005 Return-Path: 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 A515816A4CE for ; Wed, 2 Mar 2005 02:07:57 +0000 (GMT) Received: from petra.vif.com (email.vif.com [216.239.64.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C9BA43D1F for ; Wed, 2 Mar 2005 02:07:57 +0000 (GMT) (envelope-from tad@vif.com) Received: from petra.vif.com (localhost [127.0.0.1]) by petra.vif.com (8.13.1/8.13.1) with ESMTP id j2227uSV022179 for ; Tue, 1 Mar 2005 21:07:56 -0500 (EST) (envelope-from tad@vif.com) Received: (from www@localhost) by petra.vif.com (8.13.1/8.13.1/Submit) id j2227uht022178 for freebsd-net@freebsd.org; Tue, 1 Mar 2005 21:07:56 -0500 (EST) (envelope-from tad@vif.com) X-Authentication-Warning: petra.vif.com: www set sender to tad@vif.com using -f Received: from ip216-239-92-171.vif.net (ip216-239-92-171.vif.net [216.239.92.171]) by email.vif.com (Horde) with HTTP for ; Tue, 1 Mar 2005 21:07:56 -0500 Message-ID: <20050301210756.htmfzmcu80wsoc40@email.vif.com> Date: Tue, 1 Mar 2005 21:07:56 -0500 From: tad@vif.com To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.2) / FreeBSD-5.3 Subject: Re: Kern/73129 and 5.3-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Mar 2005 02:07:57 -0000 > On Thu, Feb 10, 2005 at 11:27:35AM +0100, Andre Oppermann wrote: > > > On Wed, Feb 09, 2005 at 09:48:18PM +0100, Andre Oppermann wrote: > > > > The problem is with locally generated packets which go the wrong way. > > > > This gets nasty when the box has to generate some path MTU discovery > > > > ICMP message and such. What I implemented is the correct thing to do > > > > and prevents foot-shooting. On the other hand it prevents people from > > > > forwarding local ports and such. Both sides of the coin have merit > > > > and there is no easy deciding between them or obvious right or wrong > > > > choice. [...] > The code that is currently in the tree. > -- Andre Oppermann Sorry for bringing this again, I am still getting discrepancies with ipfw fwd. Here is a my test: ProxyHost# ipfw add 10 fwd DestinationHost icmp from SourceHost to any SourceHost# ping Proxy_Host ** On 5.3 Stable (5.4-PRERELEASE #1: Sun Feb 27 20:31:49 EST 2005) and 6.0 Current (6.0-CURRENT #8: Tue Mar 1 12:32:33 EST 2005) I get replies from ProxyHost without any forwarding to DestinationHost ** On 4-x and 5.2.1 Fwd works and packets hit DestinationHost -Talal From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 03:48:21 2005 Return-Path: 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 71ABD16A4CE for ; Wed, 2 Mar 2005 03:48:21 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15B9D43D39 for ; Wed, 2 Mar 2005 03:48:21 +0000 (GMT) (envelope-from opensource.enthousiat@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so102085wri for ; Tue, 01 Mar 2005 19:48:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=JzyhRhQyEGOT28jUvQ7qFemHa/3S+meLEQkdITaSA2Ek74iV1VGk4o1dk5pqPVEjZUqPTqlrNdG5Gt9bJsbvbM3Km6c4pw99Yq9xwqQ14FCKp3WPkx2fQebpS8Kk9ZBzsHPF6/Oj0tlqhTZGCOu5b4o3u2C6B6qI1CJynVyF/yI= Received: by 10.54.4.69 with SMTP id 69mr97556wrd; Tue, 01 Mar 2005 19:47:08 -0800 (PST) Received: by 10.54.49.28 with HTTP; Tue, 1 Mar 2005 19:47:07 -0800 (PST) Message-ID: <37e131660503011947346b94fb@mail.gmail.com> Date: Tue, 1 Mar 2005 22:47:07 -0500 From: Aziz KEZZOU To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: netgraph question : how to intercept incoming IP packets of a certain type? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Aziz KEZZOU List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 03:48:21 -0000 Hi folks, Here is what I want to do : "Intercept all incoming IP packets on an Ethernet interface of a certain type (e.g RSVP) and call my own function to process, all inside the kernel" Netgraph nodes : ng_iface, nf_bpf (and probably ng_ether) look promising for this task but I can not figure out how to do it in practice... Any help is appreciated. Thanks, neo From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 06:22:53 2005 Return-Path: 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 156F016A4CE for ; Wed, 2 Mar 2005 06:22:53 +0000 (GMT) Received: from r-dd.iij4u.or.jp (r-dd.iij4u.or.jp [210.130.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F98243D53 for ; Wed, 2 Mar 2005 06:22:52 +0000 (GMT) (envelope-from demizu@dd.iij4u.or.jp) Received: from localhost (h007.p048.iij4u.or.jp [210.130.48.7]) by r-dd.iij4u.or.jp (8.11.6+IIJ/8.11.6) with ESMTP id j226MnP00597; Wed, 2 Mar 2005 15:22:49 +0900 (JST) Date: Wed, 02 Mar 2005 15:23:16 +0900 (JST) Message-Id: <20050302.152316.74752182.Noritoshi@Demizu.ORG> From: Noritoshi Demizu To: freebsd-net@freebsd.org In-Reply-To: <420BCEF7.1080603@meta.net.nz> References: <420BCEF7.1080603@meta.net.nz> X-Mailer: Mew version 4.1 on Emacs 21 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: SACK problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Mar 2005 06:22:53 -0000 > During some testing on an isolated network we have, I found some > interesting behaviour from a FreeBSD 5.3 host using TCP SACK. > > I've detailed this problem fully at: > > http://www.wand.net.nz/~stj2/nsc/emu_freebsd.html I experienced the same phenomenon. When TCP reassembly queue exceeds its limit (i.e., tcp_reass_maxseg and tcp_reass_maxqlen), tcp_reass() drops received out-of-order data segment. On the other hand, SACK list is updated by such dropped segments. Hence there arises inconsistency between reassembly queue (tp->t_segq) and SACK list (tp->sackblks[]). This is the cause of the phenomenon that I experienced. The same phenomenon could occur when tcp_drain() is called. tcp_drain() discards all reassembly queues, while it does not discard SACK list. The following patch to FreeBSD 5.3R solves my problem. It would solve Sam Jansen's problem, too. Regards, Noritoshi Demizu Index: tcp_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.252 diff -u -r1.252 tcp_input.c --- tcp_input.c 17 Aug 2004 22:05:54 -0000 1.252 +++ tcp_input.c 2 Mar 2005 05:55:27 -0000 @@ -250,6 +250,7 @@ tcp_reass_overflows++; tcpstat.tcps_rcvmemdrop++; m_freem(m); + *tlenp = 0; return (0); } @@ -261,6 +262,7 @@ if (te == NULL) { tcpstat.tcps_rcvmemdrop++; m_freem(m); + *tlenp = 0; return (0); } tp->t_segqlen++; @@ -2417,6 +2419,7 @@ thflags = tcp_reass(tp, th, &tlen, m); tp->t_flags |= TF_ACKNOW; } + if (tlen > 0) if (tp->sack_enable) tcp_update_sack_list(tp); /* Index: tcp_subr.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_subr.c,v retrieving revision 1.201.2.1.2.1 diff -u -r1.201.2.1.2.1 tcp_subr.c --- tcp_subr.c 21 Oct 2004 09:30:47 -0000 1.201.2.1.2.1 +++ tcp_subr.c 2 Mar 2005 05:55:28 -0000 @@ -818,6 +818,7 @@ tcpb->t_segqlen--; tcp_reass_qsize--; } + tcp_free_sackholes(tcpb); } INP_UNLOCK(inpb); } From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 08:29:07 2005 Return-Path: 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 F20B816A4CE; Wed, 2 Mar 2005 08:29:06 +0000 (GMT) Received: from 216.31.99-84.rev.gaoland.net (216.31.99-84.rev.gaoland.net [84.99.31.216]) by mx1.FreeBSD.org (Postfix) with SMTP id 77A4643D1D; Wed, 2 Mar 2005 08:29:00 +0000 (GMT) (envelope-from TengTamas@napcor.com) Received: from mail pickup service by 84.99.31.216 with Microsoft SMTPSVC; Wed, 02 Mar 2005 11:21:00 +0300 Content-Class: urn:content-classes:message Language: English X-MIME-Autoconverted: Yes From: "Emlyn Rony" To: owner-cvs-src@freebsd.org Date: Wed, 02 Mar 2005 09:21:00 +0100 MIME-Version: 1.0 Message-Id: <20050302082900.77A4643D1D@mx1.FreeBSD.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: devnull@freebsd.org cc: ty-advisories@freebsd.org cc: freebsd-net@freebsd.org cc: p4-releng@freebsd.org cc: marcus@freebsd.org cc: babb@freebsd.org cc: owner-p4-projects@freebsd.org Subject: You can start saving now X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Emlyn Rony List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 08:29:07 -0000 Dear Homeowner, You have been pre-approved for a $450,000 Home at a low fixed rate. We noticed that your current rate is over 5%. We are willing to give you a fixed rate of 2.9%. Take Advantage of this Limited Time opportunity! Only takes a few minutes to see what you can save! Go here: http://indenture.seaquote.com/?partid=aaks9 Best Regards, Emlyn Rony, Account Manager Matio Group LLC. r.mv - http//seaquote.com/st.html From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 12:38:38 2005 Return-Path: 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 B8D1516A4CE for ; Wed, 2 Mar 2005 12:38:38 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDC4E43D54 for ; Wed, 2 Mar 2005 12:38:37 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j22CcaUm093116; Wed, 2 Mar 2005 14:38:36 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 34346-11; Wed, 2 Mar 2005 14:38:35 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j22CcZJN093113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Mar 2005 14:38:35 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id j22CckPi047232; Wed, 2 Mar 2005 14:38:46 +0200 (EET) (envelope-from ru) Date: Wed, 2 Mar 2005 14:38:46 +0200 From: Ruslan Ermilov To: Aziz KEZZOU Message-ID: <20050302123846.GC47110@ip.net.ua> References: <37e131660503011947346b94fb@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2/5bycvrmDh4d1IB" Content-Disposition: inline In-Reply-To: <37e131660503011947346b94fb@mail.gmail.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: freebsd-net@freebsd.org Subject: Re: netgraph question : how to intercept incoming IP packets of a certain type? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Mar 2005 12:38:38 -0000 --2/5bycvrmDh4d1IB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 01, 2005 at 10:47:07PM -0500, Aziz KEZZOU wrote: > Hi folks, > Here is what I want to do : "Intercept all incoming IP packets on an > Ethernet interface of a certain type (e.g RSVP) and call my own > function to process, all inside the kernel" >=20 > Netgraph nodes : ng_iface, nf_bpf (and probably ng_ether) look > promising for this task but I can not figure out how to do it in > practice... > =20 > Any help is appreciated. Thanks, >=20 I thought Julian already answered this... You can do this with ng_ipfw(4) in -CURRENT. Or you can filter (with ng_bpf(4)) the packets of interest and forward them somewhere. Example: +---v | (upper) | rl0: [ng_ether] | (lower) | ^ | | | v | (lower) | bpf_rl0: [ng_bpf] | (upper) +---^ [bpf] should be configured to forward matching packets received on "lower" to some other hook, and non-matching packets to "upper". Similarly for packets received on "upper", forward packets of interest to some other hook, and non-matching packets to "lower". Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --2/5bycvrmDh4d1IB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFCJbPWqRfpzJluFF4RAsR1AJ96yk8iSHvAhRNoIQE4OiMJT4+/aACgjEKh Ls2NOcNL7Ug4sbiyA4Ada4Y= =Y0r1 -----END PGP SIGNATURE----- --2/5bycvrmDh4d1IB-- From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 15:20:52 2005 Return-Path: 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 E8E9416A4CF for ; Wed, 2 Mar 2005 15:20:52 +0000 (GMT) Received: from mail25.sea5.speakeasy.net (mail25.sea5.speakeasy.net [69.17.117.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id A50D843D4C for ; Wed, 2 Mar 2005 15:20:51 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 26109 invoked from network); 2 Mar 2005 15:20:51 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 2 Mar 2005 15:20:51 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j22FKeYM081583; Wed, 2 Mar 2005 10:20:44 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Bosko Milekic Date: Wed, 2 Mar 2005 10:16:36 -0500 User-Agent: KMail/1.6.2 References: <20050301000436.GA33346@xor.obsecurity.org> <20050301231438.GA25573@xor.obsecurity.org> <20050301234937.GA19502@technokratis.com> In-Reply-To: <20050301234937.GA19502@technokratis.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503021016.36953.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: Kris Kennaway cc: sparc64@FreeBSD.org cc: rwatson@FreeBSD.org cc: freebsd-sparc64@FreeBSD.org cc: net@FreeBSD.org cc: Bosko Milekic cc: bmilekic@FreeBSD.org Subject: Re: Race condition in mb_free_ext()? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Mar 2005 15:20:53 -0000 On Tuesday 01 March 2005 06:49 pm, Bosko Milekic wrote: > You know, the more and more we run into these problems specific to how > reference counting is performed, I keep wondering whether some cleverly > defined macros for dealing with common reference counting operations > would be worthwhile. I'm not saying "introduce a refcount_t type and a > full-blown abstraction," but some template-like stuff might be useful. > It took a while just to get the refcount decrement on free path free of > races on SMP, and that's only in the mbuf code. Yeah, I have those simple refcount_foo() macros that operate on ints that would work for here and things like ucreds. Being macros, each arch can override if they have a better native instruction (xadd on x86, fetchadd on ia64, etc.) > -Bosko > > On Tue, Mar 01, 2005 at 03:14:38PM -0800, Kris Kennaway wrote: > > On Tue, Mar 01, 2005 at 06:04:27PM -0500, Bosko Milekic wrote: > > > This does not appear to explain the livelock. > > > > alc and dwhite tracked it down to a missing volatile causing gcc to > > mis-optimize the loop: > > > > - cnt = *(m->m_ext.ref_cnt); > > + cnt = *(volatile u_int *)(m->m_ext.ref_cnt); > > > > I'm currently testing that. > > > > Kris -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 17:27:42 2005 Return-Path: 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 0276416A4CE; Wed, 2 Mar 2005 17:27:42 +0000 (GMT) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 143AA43D31; Wed, 2 Mar 2005 17:27:41 +0000 (GMT) (envelope-from igor@doom.homeunix.org) Received: from dialup84109-13.ip.peterstar.net ([84.204.109.13] helo=doom.homeunix.org) by voodoo.oberon.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1D6XdF-000DyM-7n; Wed, 02 Mar 2005 18:27:35 +0100 Received: from doom.homeunix.org (localhost [127.0.0.1]) by doom.homeunix.org (8.13.3/8.13.3) with ESMTP id j22HPPUx000671; Wed, 2 Mar 2005 20:25:25 +0300 (MSK) (envelope-from igor@doom.homeunix.org) Received: (from igor@localhost) by doom.homeunix.org (8.13.3/8.13.3/Submit) id j21JkUcj000988; Tue, 1 Mar 2005 22:46:30 +0300 (MSK) (envelope-from igor) Date: Tue, 1 Mar 2005 22:46:29 +0300 From: Igor Pokrovsky To: Cole Message-ID: <20050301194629.GA948@doom.homeunix.org> Mail-Followup-To: Cole , freebsd-hackers@freebsd.org, freebsd-net@freebsd.org References: <003101c51ddf$347fa420$4206000a@deadmind> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003101c51ddf$347fa420$4206000a@deadmind> User-Agent: Mutt/1.4.2.1i cc: freebsd-hackers@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Dynamically Linked Library Problem (maybe) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Mar 2005 17:27:42 -0000 On Mon, Feb 28, 2005 at 11:48:14PM +0200, Cole wrote: > Hey. > > I have a Freebsd server running freebsd-4.9-stable. > I cvsupped the ntop src last week for 3.1.1. > > I then had no problems what so ever building ntop, except for the xml plugin saying it was not built, cause it cannot find > xmlversion.h, even though I have libxml installed, and specified the right paths to the .h. But that is not the problem. > Ntop runs and works fine on this box, not a single problem that I can see. > > The problem is that, I have a few other servers, that I want to copy ntop too, but dont want to build it on all those boxes. I > created a tar with all the ntop binaries, as well as all the libraries that its linked too, as well as all the plugins that ntop > uses from both the /usr/local/lib directory as well as the plugins from the /usr/local/lib/ntop/plugins directory. I rebuilt all the > symbolic links for all the libraries and plugins and all the files that ntop was linked too. I have also checked all the permissions > on all the files and they are all the same. > > One other thing, the boxes that I am copying ntop to, are almost exact duplicates of the first box that I built ntop on, and where > it works fine. > > The problem is, when running ntop on the boxes that I copied it to, after checking all the permissions and links and everything, I > get these errors with regards to the plugins. > > Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/icmpPlugin.so' entry function [Invalid > shared object handle 0x29a14000] > Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/snmpPlugin.so' entry function [Invalid > shared object handle 0x29a16400] > Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/sflowPlugin.so' entry function [Invalid > shared object handle 0x29a19800] > Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/rrdPlugin.so' entry function [Invalid > shared object handle 0x29a1bc00] > Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/pdaPlugin.so' entry function [Invalid > shared object handle 0x2bcae400] > Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/netflowPlugin.so' entry function [Invalid > shared object handle 0x2d862800] > Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/lastSeenPlugin.so' entry function > [Invalid shared object handle 0x2d866c00] > Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/xmldumpPlugin.so' entry function [Invalid > shared object handle 0x2f697000] > > I have absolutely no idea how this has happened, and I have had this problem before, and not a single other person was able to help > me in any regards what so ever. I was hoping maybe someone would at least know what this error even means, so that I have some idea > of what I am meant to be doing to fix this. > > If anyone has any idea, I would gladly apprecaite any suggestions. It seems to me error messages mean one thing - those plugins were corrupted in some way. It is also not clear from your message - are you using net/ntop from ports tree or you are building it from sources manually? In case of problems when building from a port you'd better ping port maintainer. -ip -- You are never given enough time or money. From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 17:58:07 2005 Return-Path: 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 6D35416A4CE for ; Wed, 2 Mar 2005 17:58:07 +0000 (GMT) Received: from electra.nolink.net (electra.nolink.net [195.139.204.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EC5A43D4C for ; Wed, 2 Mar 2005 17:58:06 +0000 (GMT) (envelope-from lerik@nolink.net) Received: (qmail 51057 invoked by uid 1000); 2 Mar 2005 17:58:02 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Mar 2005 17:58:02 -0000 Date: Wed, 2 Mar 2005 18:58:02 +0100 (CET) From: Lars Erik Gullerud To: Lister In-Reply-To: <4222C64D.4050007@primetime.com> Message-ID: <20050302174915.V38850@electra.nolink.net> References: <4222C64D.4050007@primetime.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-net@freebsd.org cc: freebsd-performance@freebsd.org Subject: Re: ng_fec and cisco 2931 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Mar 2005 17:58:07 -0000 On Sun, 27 Feb 2005, Lister wrote: > > I have setup ng_fec on a machine with a quad ethernet NIC : [snip] > I have all 4 ports connected to the catalyst. From what I have read on > fast etherchannel in the cisco docs, it is supposed to detect the > etherchannel, > e.g. no commands at the switch. Lights blink on and off, change color > (orange -> green) and it seems to work ... but only on one interface in the > bundle. No faster than 80Mb. I have a 1000Mb intel card in the 2nd > test machine that does run much faster than 100. > So, is there something I have done wrong, or what? What should I expect > to get from 4 x 100 Mb ports? Not really related to FreeBSD's ng_fec at all I think, this is a common FEC issue. If you are testing this between two hosts as you indicate above, then you are getting exactly the speed you should be getting. The low-end Cisco switches offers two varieties of "load-balancing" over the FEC members, source or destination-based hash (both operate on MAC-address level). So if all your test traffic goes between a set of two mac-addresses, traffic in either direction will only flow over one member of the FEC. The higher-end devices like the 6500 series can also look at layer 3 and layer 4 flow-information to distribute the load, but basically a FEC is mostly useful in scenarios where you have a large number of hosts communicating. /leg From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 19:50:35 2005 Return-Path: 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 0A69716A4CE; Wed, 2 Mar 2005 19:50:35 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0B7F43D1D; Wed, 2 Mar 2005 19:50:34 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id B74907A41E; Wed, 2 Mar 2005 11:50:34 -0800 (PST) Message-ID: <4226190A.7040106@elischer.org> Date: Wed, 02 Mar 2005 11:50:34 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: Ruslan Ermilov References: <37e131660503011947346b94fb@mail.gmail.com> <20050302123846.GC47110@ip.net.ua> In-Reply-To: <20050302123846.GC47110@ip.net.ua> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Aziz KEZZOU cc: freebsd-net@freebsd.org Subject: Re: netgraph question : how to intercept incoming IP packets of a certain type? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Mar 2005 19:50:35 -0000 Ruslan Ermilov wrote: >On Tue, Mar 01, 2005 at 10:47:07PM -0500, Aziz KEZZOU wrote: > > >>Hi folks, >>Here is what I want to do : "Intercept all incoming IP packets on an >>Ethernet interface of a certain type (e.g RSVP) and call my own >>function to process, all inside the kernel" >> >>Netgraph nodes : ng_iface, nf_bpf (and probably ng_ether) look >>promising for this task but I can not figure out how to do it in >>practice... >> >>Any help is appreciated. Thanks, >> >> >> >I thought Julian already answered this... > > you can do it even without ng_ipfw use ng_ksocket to open a divert socket and use ipfw divert to send packets to it. >You can do this with ng_ipfw(4) in -CURRENT. Or you can filter >(with ng_bpf(4)) the packets of interest and forward them >somewhere. Example: > > +---v > | (upper) > | rl0: [ng_ether] > | (lower) > | ^ > | | > | v > | (lower) > | bpf_rl0: [ng_bpf] > | (upper) > +---^ > >[bpf] should be configured to forward matching packets received on >"lower" to some other hook, and non-matching packets to "upper". >Similarly for packets received on "upper", forward packets of >interest to some other hook, and non-matching packets to "lower". > > >Cheers, > > From owner-freebsd-net@FreeBSD.ORG Wed Mar 2 22:40:24 2005 Return-Path: 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 C297F16A4CF; Wed, 2 Mar 2005 22:40:24 +0000 (GMT) Received: from mx2.confluentasp.com (mx2.confluentasp.com [216.26.153.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45FE043D2D; Wed, 2 Mar 2005 22:40:19 +0000 (GMT) (envelope-from mikej@confluenttech.com) Received: from neo.confluentasp.local (35.in-addr.arpa.confluentasp.com [216.26.153.35] (may be forged))j22MeIdC070780; Wed, 2 Mar 2005 17:40:18 -0500 (EST) (envelope-from mikej@confluenttech.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Mar 2005 17:40:13 -0500 Message-ID: <9D7F0DF3FB16D41184010050DA90E00001C874BB@neo.confluentasp.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ng_fec and cisco 2931 Thread-Index: AcUfeMvO3epRWRJBRrC3DcsS5J5Ujw== From: "Michael G. Jung" To: , cc: freebsd-net@freebsd.org cc: freebsd-performance@freebsd.org Subject: ng_fec and cisco 2931 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Mar 2005 22:40:24 -0000 Sorry, not subscribed but here go's.... To quote cisco http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note09186a0= 080094646.shtml "EtherChannel load balancing can use either MAC addresses or IP = addresses. Also, EtherChannel load balancing can use either source or = destination, or both source and destination, addresses. The mode that = you select applies to all EtherChannels that you have configured on the = switch." On older switches that I deployed this on, say the 5000 seriers which = was based on MAC address only, on a Nx100 channel between two hosts = throughput could never exceed "N". So 4x100Mbit links between two hosts = would never exceed 100Mbit but multiple connections across the = connection would aggregate.=20 In other words etherchannel does not load balance per packet across = bonded ethernet connections but per connection. Try running tests to = multiple hosts from your FreeBSD box and see if you don't aggregate = above 100Mbit total.... Hope this is helpful. I'd be very curious to know if you find this is your issue. Kind regards, --mikej Michael Jung From owner-freebsd-net@FreeBSD.ORG Thu Mar 3 00:00:10 2005 Return-Path: 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 BCF1016A4CE for ; Thu, 3 Mar 2005 00:00:10 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8F7743D49 for ; Thu, 3 Mar 2005 00:00:09 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 1B1A61FF9A6; Thu, 3 Mar 2005 01:00:08 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id 0DC661FF9AD; Thu, 3 Mar 2005 01:00:06 +0100 (CET) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 7F9F0157D0; Wed, 2 Mar 2005 23:58:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 753E21538C; Wed, 2 Mar 2005 23:59:00 +0000 (UTC) Date: Wed, 2 Mar 2005 23:59:00 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Markus Trippelsdorf In-Reply-To: <1109147585.2574.1.camel@bsd.trippelsdorf.de> Message-ID: References: <200502230042.j1N0g1q79345@pobox.com> <1109139161.620.9.camel@bsd.trippelsdorf.de> <1109147585.2574.1.camel@bsd.trippelsdorf.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: freebsd-net@freebsd.org cc: Brian Campbell Subject: Re: skc0: no PHY found X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 03 Mar 2005 00:00:10 -0000 On Wed, 23 Feb 2005, Markus Trippelsdorf wrote: Hi all, > > > I'm running 4.7 and had the same problem ... my fix was, in > > > sk_init_yukon(), just after sc is assigned, add: > > > > > > sk_win_write_4(sc, SK_GPIO, > > > (sk_win_read_4(sc, SK_GPIO) | SK_GPIO_DIR9) & ~SK_GPIO_DAT9); > > Hi Brian, > > thank you very much. Your patch completely solved the problem. > > IMHO it should be committed to the tree. > > This is the patch: Could you please try the patch at [1] and tell me if there are any problems or if it just works. The patch is against HEAD but should also be easily applyable to RELENG_5. Thanks in advance for testing. [1] http://sources.zabbadoz.net/freebsd/patchset/if_sk.c-HEAD-20050303-01.diff -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Thu Mar 3 15:23:00 2005 Return-Path: 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 A1FB116A4CE for ; Thu, 3 Mar 2005 15:23:00 +0000 (GMT) Received: from falcon.loomes.de (smtp.loomes.de [212.40.161.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE3CE43D1D for ; Thu, 3 Mar 2005 15:22:59 +0000 (GMT) (envelope-from markus@trippelsdorf.de) Received: from port-212-202-34-139.dynamic.qsc.de ([212.202.34.139] helo=[192.68.0.2]) by falcon.loomes.de with asmtp (Exim 4.30) id 1D6sA9-0002P4-QL; Thu, 03 Mar 2005 16:22:53 +0100 From: Markus Trippelsdorf To: "Bjoern A. Zeeb" In-Reply-To: References: <200502230042.j1N0g1q79345@pobox.com> <1109139161.620.9.camel@bsd.trippelsdorf.de> <1109147585.2574.1.camel@bsd.trippelsdorf.de> Content-Type: text/plain Date: Thu, 03 Mar 2005 16:22:52 +0100 Message-Id: <1109863372.1920.5.camel@bsd.trippelsdorf.de> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Brian Campbell Subject: Re: skc0: no PHY found X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 03 Mar 2005 15:23:00 -0000 On Wed, 2005-03-02 at 23:59 +0000, Bjoern A. Zeeb wrote: > Could you please try the patch at [1] and tell me if there are any > problems or if it just works. > > The patch is against HEAD but should also be easily applyable > to RELENG_5. The patch does not apply cleanly against RELENG_5: root pci # patch -i /home/markus/if_sk.c-HEAD-20050303-01.diff -p -C ... Hunk #33 failed at 1696. Hunk #34 failed at 1813. ... Maybe you could generate a new patch? Thanks. __ Markus From owner-freebsd-net@FreeBSD.ORG Thu Mar 3 16:53:32 2005 Return-Path: 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 049C116A4CF for ; Thu, 3 Mar 2005 16:53:32 +0000 (GMT) Received: from falcon.loomes.de (smtp.loomes.de [212.40.161.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CBCA43D48 for ; Thu, 3 Mar 2005 16:53:31 +0000 (GMT) (envelope-from markus@trippelsdorf.de) Received: from port-212-202-34-139.dynamic.qsc.de ([212.202.34.139] helo=[192.68.0.2]) by falcon.loomes.de with asmtp (Exim 4.30) id 1D6tZo-00065N-Tx; Thu, 03 Mar 2005 17:53:28 +0100 From: Markus Trippelsdorf To: "Bjoern A. Zeeb" In-Reply-To: References: <200502230042.j1N0g1q79345@pobox.com> <1109139161.620.9.camel@bsd.trippelsdorf.de> <1109147585.2574.1.camel@bsd.trippelsdorf.de> Content-Type: text/plain Date: Thu, 03 Mar 2005 17:53:27 +0100 Message-Id: <1109868807.658.3.camel@bsd.trippelsdorf.de> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Brian Campbell Subject: Re: skc0: no PHY found X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 03 Mar 2005 16:53:32 -0000 On Wed, 2005-03-02 at 23:59 +0000, Bjoern A. Zeeb wrote: > On Wed, 23 Feb 2005, Markus Trippelsdorf wrote: > > Hi all, > > > > > I'm running 4.7 and had the same problem ... my fix was, in > > > > sk_init_yukon(), just after sc is assigned, add: > > > > > > > > sk_win_write_4(sc, SK_GPIO, > > > > (sk_win_read_4(sc, SK_GPIO) | SK_GPIO_DIR9) & ~SK_GPIO_DAT9); > > > Hi Brian, > > > thank you very much. Your patch completely solved the problem. > > > IMHO it should be committed to the tree. > > > > This is the patch: > > Could you please try the patch at [1] and tell me if there are any > problems or if it just works. > > The patch is against HEAD but should also be easily applyable > to RELENG_5. > Your patch is working fine here (running HEAD). Thank you. __ Markus From owner-freebsd-net@FreeBSD.ORG Thu Mar 3 23:25:01 2005 Return-Path: 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 19E2616A4CE; Thu, 3 Mar 2005 23:25:01 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 931F643D2F; Thu, 3 Mar 2005 23:25:00 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 76585AC956; Fri, 4 Mar 2005 00:24:58 +0100 (CET) Date: Fri, 4 Mar 2005 00:24:58 +0100 From: Pawel Jakub Dawidek To: Luigi Rizzo Message-ID: <20050303232458.GO9291@darkness.comp.waw.pl> References: <20050217161031.A46700@xorpc.icir.org> <200503011642.48813.jhb@FreeBSD.org> <20050301162949.A64187@xorpc.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QKFUq+IbM9AW97yF" Content-Disposition: inline In-Reply-To: <20050301162949.A64187@xorpc.icir.org> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: dima <_pppp@mail.ru> cc: John Baldwin cc: net@FreeBSD.org Subject: Re: Giant-free polling [PATCH] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 03 Mar 2005 23:25:01 -0000 --QKFUq+IbM9AW97yF Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 01, 2005 at 04:29:49PM -0800, Luigi Rizzo wrote: +> [cc-ing net@freebsd.org to get more opinions] +>=20 +> On Tue, Mar 01, 2005 at 04:42:48PM -0500, John Baldwin wrote: +> > On Thursday 17 February 2005 07:10 pm, Luigi Rizzo wrote: +> > > i am no expert about the locking but i see places where +> > > you grab polling_lock followed by ifnet_lock, and others where +> > > you use the opposite order. This seems prone to deadlock... +> >=20 +> > Yes, it basically seems that the polling_lock should be removed and ju= st the=20 +> > ifnet_lock used because the the ifnet_lock is already always held when= the=20 +> > polling_lock is locked. Yeah, but we cannot grap ifnet_lock in polling code, because this is internal mutex, not visible from outside. I was thinking about moving ifnet_lock into ifnet structure... +> this said, if the lock requests are blocking, you basically end +> up with the polling loops always contending for the locks, with only one +> doing actual work and the other one always busy-waiting. +>=20 +> Assuming the primitive exists, I think the correct way to implement +> SMP polling is to use non-blocking locks, something like this +> (in pseudocode) +>=20 +> poll_loop() { +> have_polling_lock =3D try_get_lock(polling_lock) +> foreach(ifp in polled_interfaces) { +> if (have_polling_lock) +> have_ifp_lock =3D get_lock(ifp) // returns true +> else +> have_ifp_lock =3D try_get_lock(ifp) +> if (have_ifp_lock) { +> ifp->poll(); +> release_lock(ifp) +> } +> } +> if (have_polling_lock) +> release_lock(polling_lock); +> } +>=20 +> so additional polling processes after the first one will not +> block on busy interfaces and move forward instead. +> This should remove a bit of contention, and let separate processes actua= lly +> work on different interfaces. I think we should just implement per-interface idlepoll threads, so we can run polling code on many CPUs for many interfaces. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --QKFUq+IbM9AW97yF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFCJ5zKForvXbEpPzQRAi2lAKC2NdMRuUkUm/0YQuu8bJo6fEM/HwCg0OZy axqDwvGKiDlorK9INal9ask= =wq7q -----END PGP SIGNATURE----- --QKFUq+IbM9AW97yF-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 4 01:44:55 2005 Return-Path: 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 7EF0516A4CE; Fri, 4 Mar 2005 01:44:55 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39E6343D66; Fri, 4 Mar 2005 01:44:55 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 6666946B06; Thu, 3 Mar 2005 20:44:29 -0500 (EST) Date: Fri, 4 Mar 2005 01:42:26 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Pawel Jakub Dawidek In-Reply-To: <20050303232458.GO9291@darkness.comp.waw.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: dima <_pppp@mail.ru> cc: Luigi Rizzo cc: John Baldwin cc: net@FreeBSD.org Subject: Re: Giant-free polling [PATCH] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 04 Mar 2005 01:44:55 -0000 On Fri, 4 Mar 2005, Pawel Jakub Dawidek wrote: > On Tue, Mar 01, 2005 at 04:29:49PM -0800, Luigi Rizzo wrote: > +> [cc-ing net@freebsd.org to get more opinions] > +> > +> On Tue, Mar 01, 2005 at 04:42:48PM -0500, John Baldwin wrote: > +> > On Thursday 17 February 2005 07:10 pm, Luigi Rizzo wrote: > +> > > i am no expert about the locking but i see places where > +> > > you grab polling_lock followed by ifnet_lock, and others where > +> > > you use the opposite order. This seems prone to deadlock... > +> > > +> > Yes, it basically seems that the polling_lock should be removed and just the > +> > ifnet_lock used because the the ifnet_lock is already always held when the > +> > polling_lock is locked. > > Yeah, but we cannot grap ifnet_lock in polling code, because this is > internal mutex, not visible from outside. I was thinking about moving > ifnet_lock into ifnet structure... One caution here -- while currently the vast majority of our drivers protect per-softc state with a single mutex, in the future this will not be true. Many network cards are implemented with fairly independent receive and transmit units, so it's easy to imagine protecting receive and transmit with separate mutexes so that receive and transmit can occur simultaenously and independently -- for example, for packet bridging or forwarding. Robert N M Watson From owner-freebsd-net@FreeBSD.ORG Fri Mar 4 10:59:45 2005 Return-Path: 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 C3B9E16A4CE; Fri, 4 Mar 2005 10:59:45 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 671EA43D2D; Fri, 4 Mar 2005 10:59:45 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.8) with ESMTP id j24AxjCg000815; Fri, 4 Mar 2005 02:59:45 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j24AxgZh000814; Fri, 4 Mar 2005 02:59:42 -0800 (PST) (envelope-from rizzo) Date: Fri, 4 Mar 2005 02:59:42 -0800 From: Luigi Rizzo To: Pawel Jakub Dawidek Message-ID: <20050304025942.E134@xorpc.icir.org> References: <200503011642.48813.jhb@FreeBSD.org> <20050301162949.A64187@xorpc.icir.org> <20050303232458.GO9291@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20050303232458.GO9291@darkness.comp.waw.pl>; from pjd@freebsd.org on Fri, Mar 04, 2005 at 12:24:58AM +0100 cc: dima <_pppp@mail.ru> cc: John Baldwin cc: net@freebsd.org Subject: Polling objectives (was Re: Giant-free polling [PATCH]) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 04 Mar 2005 10:59:45 -0000 On Fri, Mar 04, 2005 at 12:24:58AM +0100, Pawel Jakub Dawidek wrote: ... (luigi) > +> this said, if the lock requests are blocking, you basically end > +> up with the polling loops always contending for the locks, with only one > +> doing actual work and the other one always busy-waiting. ... (pawel) > I think we should just implement per-interface idlepoll threads, so we can > run polling code on many CPUs for many interfaces. no this won't work, because this would leave the problem of scheduling the idlepoll threads unresolved, and you would end up with a huge overhead context-switching the idlepoll threads, or with one (or a few) interfaces getting polled and saturating resources. For the records, even the UP case had this problem -- in the initial implementation of polling, the first busy interface encountered in the polling loop would easily saturate the entire ipintrq causing other packets to be dropped systematically. I would like to restate the motivations for using polling instead of interrupts. Among the advantages of polling there were: 1. reduction of context switches: not one per interrupt, but one per timer tick (this is orders or magnitude smaller on a busy box, where you do care for the overhead); If you don't implement this, you will not improve the throughput of the box under load, and possibly will not even be able to prevent livelock 2. predictable scheduling of kernel vs userland work; If you don't implement this, once again you won't be able to prevent livelock 3. predictable scheduling of work among the various interfaces. if you don't implement this, you might risk unfairness in the handling of traffic, which can even lead to systematic starvation of certain interfaces. The UP polling code did implement all of the above. I would suggest people interested in implementing SMP polling to make sure that their _design_ covers the above issues _before_ coming up with patches. I _do not_ have a complete solution. Just coming up with something that is called polling but has none of the above properties would be misleading for the users (who do associate features to names) and a regression for the project. IMHO. thanks luigi > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! From owner-freebsd-net@FreeBSD.ORG Fri Mar 4 12:50:16 2005 Return-Path: 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 3A70216A4CE for ; Fri, 4 Mar 2005 12:50:16 +0000 (GMT) Received: from krichy.tvnetwork.hu (krichy.TvNetWork.Hu [80.95.68.194]) by mx1.FreeBSD.org (Postfix) with SMTP id B7D1643D41 for ; Fri, 4 Mar 2005 12:50:14 +0000 (GMT) (envelope-from krichy@tvnetwork.hu) Received: (qmail 22219 invoked by uid 1000); 4 Mar 2005 12:50:13 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 4 Mar 2005 12:50:13 -0000 Date: Fri, 4 Mar 2005 13:50:11 +0100 (CET) From: Richard Kojedzinszky To: freebsd-net@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1599128132-1310349068-1109940611=:21725" Subject: ng_one2many.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 04 Mar 2005 12:50:16 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1599128132-1310349068-1109940611=:21725 Content-Type: TEXT/PLAIN; charset=US-ASCII -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all! I was happy to configure ng_one2many on my fbsd box, but when I tried to collect statistics about the many* links of such a node, I've got an EINVAL. I've looked for it iun the sources, and i found that there may be a typo, where queries only for many0 are allowed. I attach a fix, please let me know if it is right. I am using 4_10_RELENG from cvsup. Thanks in advance, Kojedzinszky Richard TvNetWork Rt. E-mail: krichy@tvnetwork.hu PGP: 0x24E79141 Fingerprint = 6847 ECFF EF58 0C09 18A5 16CF 270F 0C6F 24E7 9141 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Made with pgp4pine 1.75-6 iD8DBQFCKFmFJw8MbyTnkUERAiLkAJ9eDy5Dn7Rso2NoGvxced5ACJNnQgCZAecT nSDiGVMQlSO8H0xkalshfdA= =0RMF -----END PGP SIGNATURE----- --1599128132-1310349068-1109940611=:21725 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="ng_one2many.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="ng_one2many.patch" LS0tIHNyYy9zeXMvbmV0Z3JhcGgvbmdfb25lMm1hbnkuYwlXZWQgSnVsICAz IDAxOjQ0OjAyIDIwMDINCisrKyAvaG9tZS9rcmljaHkvbmdfb25lMm1hbnku YwlGcmkgTWFyICA0IDEzOjQ5OjAxIDIwMDUNCkBAIC0zMzYsNyArMzM2LDcg QEANCiAJCQlsaW5rTnVtID0gKigoaW50MzJfdCAqKW1zZy0+ZGF0YSk7DQog CQkJaWYgKGxpbmtOdW0gPT0gTkdfT05FMk1BTllfT05FX0xJTktOVU0pDQog CQkJCWxpbmsgPSAmcHJpdi0+b25lOw0KLQkJCWVsc2UgaWYgKGxpbmtOdW0g PT0gMA0KKwkJCWVsc2UgaWYgKGxpbmtOdW0gPj0gMA0KIAkJCSAgICAmJiBs aW5rTnVtIDwgTkdfT05FMk1BTllfTUFYX0xJTktTKSB7DQogCQkJCWxpbmsg PSAmcHJpdi0+bWFueVtsaW5rTnVtXTsNCiAJCQl9IGVsc2Ugew0K --1599128132-1310349068-1109940611=:21725-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 4 13:32:46 2005 Return-Path: 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 0D20916A4CE for ; Fri, 4 Mar 2005 13:32:45 +0000 (GMT) Received: from f22.mail.ru (f22.mail.ru [194.67.57.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C8C343D5A for ; Fri, 4 Mar 2005 13:32:45 +0000 (GMT) (envelope-from _pppp@mail.ru) Received: from mail by f22.mail.ru with local id 1D7Cv5-0004mV-00; Fri, 04 Mar 2005 16:32:43 +0300 Received: from [81.200.13.122] by win.mail.ru with HTTP; Fri, 04 Mar 2005 16:32:43 +0300 From: dima <_pppp@mail.ru> To: Luigi Rizzo Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [81.200.13.122] Date: Fri, 04 Mar 2005 16:32:43 +0300 In-Reply-To: <20050304025942.E134@xorpc.icir.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: cc: net@freebsd.org Subject: Re: Polling objectives (was Re: Giant-free polling [PATCH]) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: dima <_pppp@mail.ru> List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 13:32:46 -0000 -----Original Message----- From: Luigi Rizzo To: Pawel Jakub Dawidek Date: Fri, 4 Mar 2005 02:59:42 -0800 Subject: Polling objectives (was Re: Giant-free polling [PATCH]) > > On Fri, Mar 04, 2005 at 12:24:58AM +0100, Pawel Jakub Dawidek wrote: > .... > (luigi) >> +> this said, if the lock requests are blocking, you basically end >> +> up with the polling loops always contending for the locks, with only one >> +> doing actual work and the other one always busy-waiting. > .... > > (pawel) >> I think we should just implement per-interface idlepoll threads, so we can >> run polling code on many CPUs for many interfaces. > > no this won't work, because this would leave the problem of > scheduling the idlepoll threads unresolved, and > you would end up with a huge overhead context-switching the > idlepoll threads, or with one (or a few) interfaces getting > polled and saturating resources. > > For the records, even the UP case had this problem -- in the initial > implementation of polling, the first busy interface encountered in > the polling loop would easily saturate the entire ipintrq causing > other packets to be dropped systematically. > > I would like to restate the motivations for using polling instead > of interrupts. Among the advantages of polling there were: > > 1. reduction of context switches: not one per interrupt, but > one per timer tick (this is orders or magnitude smaller on > a busy box, where you do care for the overhead); > > If you don't implement this, you will not improve the > throughput of the box under load, and possibly will not > even be able to prevent livelock > > 2. predictable scheduling of kernel vs userland work; > > If you don't implement this, once again you won't be able > to prevent livelock > > 3. predictable scheduling of work among the various interfaces. > > if you don't implement this, you might risk unfairness in > the handling of traffic, which can even lead to systematic > starvation of certain interfaces. > > The UP polling code did implement all of the above. > > I would suggest people interested in implementing SMP polling > to make sure that their _design_ covers the above issues _before_ > coming up with patches. I _do not_ have a complete solution. Well, my primary idea was to replace Giant with a personal lock for polling (so it would become independent of any blockings in the kernel; thus polling performance will be more predictable). That's why I didn't change *your* design in any way. Since Giant is removed we can let SMP people use polling also. Let's discuss the scheduling sanity then... The polling loop can be scheduled from 3 points: 1. hardclock_process() -- this is a per-CPU one, thus it's quite ok if all CPUs can poll different interfaces (it is possible in the second version of the patch because of mtx_trylock() in the loop). 2. trap() -- I don't like the current implementation; it should probably check for the source of interrupt, so say a disk-intensive task wouldn't bring polling overhead. But note that scheduling frequency isn't affected. 3. poll_idle() -- this is the strangest one since it isn't mentioned anywhere else in the kernel... I don't like the Pawel's idea about per-interface threads also... PS: my question about locking in ether_poll_register() is still actual. I think pr[] should be protected by sx while adding a new handler. > > Just coming up with something that is called polling but > has none of the above properties would be misleading for > the users (who do associate features to names) and a regression > for the project. IMHO. > > thanks > luigi > >> -- >> Pawel Jakub Dawidek http://www.wheel.pl >> pjd@FreeBSD.org http://www.FreeBSD.org >> FreeBSD committer Am I Evil? Yes, I Am! From owner-freebsd-net@FreeBSD.ORG Fri Mar 4 13:44:07 2005 Return-Path: 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 4265916A4CE for ; Fri, 4 Mar 2005 13:44:07 +0000 (GMT) Received: from vvi.com (mail.vvi.com [207.68.114.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id B678343D41 for ; Fri, 4 Mar 2005 13:44:06 +0000 (GMT) (envelope-from lbland@vvi.com) Received: from [207.68.114.251] (account lbland [207.68.114.251] verified) by vvi.com (CommuniGate Pro SMTP 4.2.4) with ESMTP id 4910306 for freebsd-net@freebsd.org; Fri, 04 Mar 2005 08:47:50 -0500 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <69ec4799a574aeae723c687c3c2db15f@vvi.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: freebsd-net@freebsd.org From: lbland Date: Fri, 4 Mar 2005 08:47:49 -0500 X-Mailer: Apple Mail (2.619.2) Subject: TCP window scale option setting? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 04 Mar 2005 13:44:07 -0000 hi- In section 2.5 of the Stevens book it says "we wil see how to effect this [window scale] option with SO_RCVBUF socket option (Section 7.5)". But, when I get to Section 7.5 it doesn't say anything about it that I can find. I searched the whole book, and then googled and then grep'd the header files to hack it. I see some related macros, but nothing definitive. I can't find enough to figure it out. It seems I can use setsockopt() to implicitly maybe or maybe not define it, but then I have no way of checking to make sure it stuck during the initial negotiation. How do I get the current TCP window scale setting? How do I set the TCP window scale setting? thanks!- -lance From owner-freebsd-net@FreeBSD.ORG Fri Mar 4 14:51:23 2005 Return-Path: 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 74ECE16A4CE for ; Fri, 4 Mar 2005 14:51:23 +0000 (GMT) Received: from te-clan.ch (ns1.te-clan.ch [217.118.194.40]) by mx1.FreeBSD.org (Postfix) with SMTP id 5346A43D5C for ; Fri, 4 Mar 2005 14:51:22 +0000 (GMT) (envelope-from bachi@te-clan.ch) Received: (qmail 44720 invoked from network); 4 Mar 2005 14:50:34 -0000 Received: from unknown (HELO te-clan.ch) (127.0.0.1) by te-clan.ch with SMTP; 4 Mar 2005 14:50:34 -0000 Received: from 193.134.254.115 (SquirrelMail authenticated user bachi@te-clan.ch) by webmail.te-clan.ch with HTTP; Fri, 4 Mar 2005 15:50:34 +0100 (CET) Message-ID: <40850.193.134.254.115.1109947834.squirrel@webmail.te-clan.ch> Date: Fri, 4 Mar 2005 15:50:34 +0100 (CET) From: To: X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.10) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: xsocket unique id X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 04 Mar 2005 14:51:23 -0000 hi! i would like to develop a gui app, based on gtk+, to monitor all socket states like tcpview (http://www.sysinternals.com/ntw2k/source/tcpview.shtml) on ms window. my kernel experience is small, so my template is sockstat. my question is: which variable in the xsocket or socket structure, is the unique id of a socket? thanks! greets Andreas Bachmann From owner-freebsd-net@FreeBSD.ORG Fri Mar 4 16:06:05 2005 Return-Path: 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 88C7316A4CE for ; Fri, 4 Mar 2005 16:06:05 +0000 (GMT) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5068143D2D for ; Fri, 4 Mar 2005 16:06:04 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id j24G633e023310; Fri, 4 Mar 2005 19:06:03 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Fri, 4 Mar 2005 19:06:03 +0300 (MSK) From: Maxim Konovalov To: lbland In-Reply-To: <69ec4799a574aeae723c687c3c2db15f@vvi.com> Message-ID: <20050304190529.A23172@mp2.macomnet.net> References: <69ec4799a574aeae723c687c3c2db15f@vvi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: TCP window scale option setting? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 04 Mar 2005 16:06:05 -0000 On Fri, 4 Mar 2005, 08:47-0500, lbland wrote: > hi- > > In section 2.5 of the Stevens book it says "we wil see how to effect this > [window scale] option with SO_RCVBUF socket option (Section 7.5)". > > But, when I get to Section 7.5 it doesn't say anything about it that I can > find. I searched the whole book, and then googled and then grep'd the header > files to hack it. I see some related macros, but nothing definitive. I can't > find enough to figure it out. It seems I can use setsockopt() to implicitly > maybe or maybe not define it, but then I have no way of checking to make sure > it stuck during the initial negotiation. > > How do I get the current TCP window scale setting? > > How do I set the TCP window scale setting? man 4 tcp, sysctl net.inet.tcp.rfc1323 -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Fri Mar 4 16:08:09 2005 Return-Path: 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 E268416A4CE for ; Fri, 4 Mar 2005 16:08:09 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8A4643D1F for ; Fri, 4 Mar 2005 16:08:09 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.8) with ESMTP id j24G89RH004247; Fri, 4 Mar 2005 08:08:09 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j24G89J8004246; Fri, 4 Mar 2005 08:08:09 -0800 (PST) (envelope-from rizzo) Date: Fri, 4 Mar 2005 08:08:09 -0800 From: Luigi Rizzo To: dima <_pppp@mail.ru> Message-ID: <20050304080809.A4180@xorpc.icir.org> References: <20050304025942.E134@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from _pppp@mail.ru on Fri, Mar 04, 2005 at 04:32:43PM +0300 cc: net@freebsd.org Subject: Re: Polling objectives (was Re: Giant-free polling [PATCH]) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 04 Mar 2005 16:08:10 -0000 On Fri, Mar 04, 2005 at 04:32:43PM +0300, dima wrote: ... > PS: my question about locking in ether_poll_register() is still actual. I think pr[] should be protected by sx while adding a new handler. ether_poll_register() was called by *foo_intr() so in 4.x it was protected by splimp() or Giant. It is likely that now, with drivers being no more under a single lock, you need to protect it as well with a private lock. cheers luigi From owner-freebsd-net@FreeBSD.ORG Fri Mar 4 16:11:00 2005 Return-Path: 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 7E76616A4CF for ; Fri, 4 Mar 2005 16:11:00 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F59843D48 for ; Fri, 4 Mar 2005 16:11:00 +0000 (GMT) (envelope-from opensource.enthousiat@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so740053wri for ; Fri, 04 Mar 2005 08:10:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=C6rMcPdkAV7PmOy2phs0ezQqqHMxpcxTgUuv/HT7xw7AKGTyZOnW8WVrA+gO02FuI+9cQHZKBo03k8KSHhLJk2lmUj78fivnI+hjcFvJck/aA8GYtcEHVegunRaoa+7F+BUdzxjJWrA4XOXOEWTf/uewaMC2AY1preVttXCNRaY= Received: by 10.54.34.52 with SMTP id h52mr15086wrh; Fri, 04 Mar 2005 08:08:34 -0800 (PST) Received: by 10.54.49.28 with HTTP; Fri, 4 Mar 2005 08:07:34 -0800 (PST) Message-ID: <37e13166050304080715525d7e@mail.gmail.com> Date: Fri, 4 Mar 2005 11:07:34 -0500 From: Aziz KEZZOU To: freebsd-net@freebsd.org, hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: generic network protocols parser ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Aziz KEZZOU List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 16:11:00 -0000 Hi all, I am wondering if any one knows about a generic parser which takes a packet (mbuf) of a certain protocol (e.g RSVP ) as input and generates some data structre representing the packet ? I've been searching for a while and found that ethereal and tcpdump for example use specific data structres and functions to dissect each protocol packets. Is this the only approach possible ? My supervisor suggested using a TLV (Type/Length/Value) approach instead. Any opinions about that? If no such a parser exists is there any practical reason why ? Thanks, Aziz From owner-freebsd-net@FreeBSD.ORG Fri Mar 4 16:21:52 2005 Return-Path: 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 5AAD616A4CE; Fri, 4 Mar 2005 16:21:52 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA99043D31; Fri, 4 Mar 2005 16:21:51 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])j24GLnt2090689; Fri, 4 Mar 2005 11:21:49 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.3/8.12.1/Submit) id j24GLn9I090688; Fri, 4 Mar 2005 11:21:49 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Fri, 4 Mar 2005 11:21:49 -0500 From: Bosko Milekic To: Aziz KEZZOU Message-ID: <20050304162149.GA90499@technokratis.com> References: <37e13166050304080715525d7e@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37e13166050304080715525d7e@mail.gmail.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-net@freebsd.org cc: hackers@freebsd.org Subject: Re: generic network protocols parser ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 04 Mar 2005 16:21:52 -0000 On Fri, Mar 04, 2005 at 11:07:34AM -0500, Aziz KEZZOU wrote: > Hi all, > I am wondering if any one knows about a generic parser which takes a > packet (mbuf) of a certain protocol (e.g RSVP ) as input and generates > some data structre representing the packet ? > > I've been searching for a while and found that ethereal and tcpdump > for example use specific data structres and functions to dissect each > protocol packets. Is this the only approach possible ? > > My supervisor suggested using a TLV (Type/Length/Value) approach > instead. Any opinions about that? > > If no such a parser exists is there any practical reason why ? > > Thanks, > Aziz You can only go so far with generic parsing. Eventually you will want some protocol specific value to be extracted and your parser will have to know about what the packet looks like. What are you trying to do, exactly? -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Fri Mar 4 16:23:35 2005 Return-Path: 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 A92DF16A4CE for ; Fri, 4 Mar 2005 16:23:35 +0000 (GMT) Received: from te-clan.ch (ns1.te-clan.ch [217.118.194.40]) by mx1.FreeBSD.org (Postfix) with SMTP id 7DF2943D2D for ; Fri, 4 Mar 2005 16:23:34 +0000 (GMT) (envelope-from bachi@te-clan.ch) Received: (qmail 44964 invoked from network); 4 Mar 2005 16:22:49 -0000 Received: from unknown (HELO te-clan.ch) (127.0.0.1) by te-clan.ch with SMTP; 4 Mar 2005 16:22:49 -0000 Received: from 193.134.254.115 (SquirrelMail authenticated user bachi@te-clan.ch) by webmail.te-clan.ch with HTTP; Fri, 4 Mar 2005 17:22:49 +0100 (CET) Message-ID: <29347.193.134.254.115.1109953369.squirrel@webmail.te-clan.ch> Date: Fri, 4 Mar 2005 17:22:49 +0100 (CET) From: To: In-Reply-To: <37e13166050304080715525d7e@mail.gmail.com> References: <37e13166050304080715525d7e@mail.gmail.com> X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.10) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: freebsd-net@freebsd.org Subject: Re: generic network protocols parser ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 04 Mar 2005 16:23:35 -0000 i'm not an expert, but you can attach to bpf (berkeley packet filter) greets Andreas Bachmann > Hi all, > I am wondering if any one knows about a generic parser which takes a > packet (mbuf) of a certain protocol (e.g RSVP ) as input and generates > some data structre representing the packet ? > > I've been searching for a while and found that ethereal and tcpdump for > example use specific data structres and functions to dissect each > protocol packets. Is this the only approach possible ? > > My supervisor suggested using a TLV (Type/Length/Value) approach > instead. Any opinions about that? > > If no such a parser exists is there any practical reason why ? > > Thanks, > Aziz > _______________________________________________ > 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 Mar 4 16:35:53 2005 Return-Path: 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 A846C16A4CE for ; Fri, 4 Mar 2005 16:35:53 +0000 (GMT) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EAB943D31 for ; Fri, 4 Mar 2005 16:35:53 +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 postfix3-1.free.fr (Postfix) with ESMTP id 03AE51734F7; Fri, 4 Mar 2005 17:35:51 +0100 (CET) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id EFCDF407C; Fri, 4 Mar 2005 17:35:07 +0100 (CET) Date: Fri, 4 Mar 2005 17:35:07 +0100 From: Jeremie Le Hen To: bachi@te-clan.ch Message-ID: <20050304163507.GB15329@obiwan.tataz.chchile.org> References: <37e13166050304080715525d7e@mail.gmail.com> <29347.193.134.254.115.1109953369.squirrel@webmail.te-clan.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29347.193.134.254.115.1109953369.squirrel@webmail.te-clan.ch> User-Agent: Mutt/1.5.7i cc: opensource.enthousiat@gmail.com cc: freebsd-net@freebsd.org Subject: Re: generic network protocols parser ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 04 Mar 2005 16:35:53 -0000 Hi, please, avoid top-posting :-). > i'm not an expert, but you can attach to bpf (berkeley packet filter) With a correct filter, bpf(4) will help him to get only RSVP packets. But Aziz is more likely looking for accessing RSVP header fields individually, a task bpf(4) can't help for. A manually parse will be needed, although he succeeds in re-using the Ethereal plug'in, but I don't know if it is feasible. Regards, -- Jeremie Le Hen jeremie at le-hen dot org From owner-freebsd-net@FreeBSD.ORG Fri Mar 4 17:47:14 2005 Return-Path: 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 2A17316A4CE; Fri, 4 Mar 2005 17:47:14 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D52543D53; Fri, 4 Mar 2005 17:47:13 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) j24HlBV1093337; Fri, 4 Mar 2005 09:47:12 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (nat-202.43.223.241.hongkong.corp.yahoo.com [202.43.223.241]) by mail.meer.net (8.12.10/8.12.10/meer) with ESMTP id j24Hl6DY051049; Fri, 4 Mar 2005 09:47:07 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Sat, 05 Mar 2005 01:47:05 +0800 Message-ID: From: gnn@freebsd.org To: Aziz KEZZOU In-Reply-To: <37e13166050304080715525d7e@mail.gmail.com> References: <37e13166050304080715525d7e@mail.gmail.com> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.7.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org cc: hackers@freebsd.org Subject: Re: generic network protocols parser ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 04 Mar 2005 17:47:14 -0000 At Fri, 4 Mar 2005 11:07:34 -0500, Aziz KEZZOU wrote: > > Hi all, > I am wondering if any one knows about a generic parser which takes a > packet (mbuf) of a certain protocol (e.g RSVP ) as input and generates > some data structre representing the packet ? > > I've been searching for a while and found that ethereal and tcpdump > for example use specific data structres and functions to dissect each > protocol packets. Is this the only approach possible ? > > My supervisor suggested using a TLV (Type/Length/Value) approach > instead. Any opinions about that? > > If no such a parser exists is there any practical reason why ? > You might want to look at libnet and libnet-ng. Start here: http://www.packetfactory.net/libnet/ Perhaps not exactly what you want but the beginnings are there. Later, George From owner-freebsd-net@FreeBSD.ORG Fri Mar 4 19:03:33 2005 Return-Path: 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 4311116A4CE; Fri, 4 Mar 2005 19:03:33 +0000 (GMT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2624443D2D; Fri, 4 Mar 2005 19:03:33 +0000 (GMT) (envelope-from peter.sheh@hp.com) Received: from cacexg12.americas.cpqcorp.net (cacexg12.americas.cpqcorp.net [16.92.1.72]) by palrel11.hp.com (Postfix) with ESMTP id 4D9B65F1C; Fri, 4 Mar 2005 11:03:29 -0800 (PST) Received: from cacexc04.americas.cpqcorp.net ([16.92.1.26]) by cacexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Mar 2005 11:02:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Mar 2005 11:02:56 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS question ??? Thread-Index: AcR5PRBpbniWztVgSYGec4+wrt8oJSnpusHQAAItMeA= From: "Sheh, Peter" To: , X-OriginalArrivalTime: 04 Mar 2005 19:02:57.0409 (UTC) FILETIME=[C7112F10:01C520EC] cc: "Sheh, Peter" Subject: DNS question ??? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 04 Mar 2005 19:03:33 -0000 Hi all, =20 Hope someone can help me with this question: "What does DNS do when the same hostname is reported from multiple systems with different IP addresses? " Thx...Peter From owner-freebsd-net@FreeBSD.ORG Fri Mar 4 19:14:43 2005 Return-Path: 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 30F3316A4CE for ; Fri, 4 Mar 2005 19:14:43 +0000 (GMT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3F8343D3F for ; Fri, 4 Mar 2005 19:14:42 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id j24JEg3d004443; Fri, 4 Mar 2005 11:14:42 -0800 (PST) Received: from [10.1.1.245] (nfw1.codefab.com [199.103.21.225]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id j24JEfeY012019; Fri, 4 Mar 2005 11:14:42 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2243aaef81a7f3699d6ec84583498e4a@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Fri, 4 Mar 2005 14:14:40 -0500 To: "Sheh, Peter" X-Mailer: Apple Mail (2.619.2) cc: freebsd-net@freebsd.org Subject: Re: DNS question ??? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 04 Mar 2005 19:14:43 -0000 On Mar 4, 2005, at 2:02 PM, Sheh, Peter wrote: [ ...crossposting trimmed... ] > Hope someone can help me with this question: > "What does DNS do when the same hostname is reported from multiple > systems with different IP addresses? " The DNS returns the same hostname for each of the IPs which have a PTR record listing that hostname. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Fri Mar 4 19:26:57 2005 Return-Path: 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 EE10016A4CE for ; Fri, 4 Mar 2005 19:26:57 +0000 (GMT) Received: from te-clan.ch (ns1.te-clan.ch [217.118.194.40]) by mx1.FreeBSD.org (Postfix) with SMTP id DB7DF43D1F for ; Fri, 4 Mar 2005 19:26:56 +0000 (GMT) (envelope-from bachi@te-clan.ch) Received: (qmail 45427 invoked from network); 4 Mar 2005 19:26:15 -0000 Received: from unknown (HELO notebook.bachi.net) (80.219.63.44) by te-clan.ch with SMTP; 4 Mar 2005 19:26:15 -0000 From: Andreas Bachmann To: Garrett Wollman In-Reply-To: <200503041913.j24JDfD8078029@khavrinen.lcs.mit.edu> References: <40850.193.134.254.115.1109947834.squirrel@webmail.te-clan.ch> <200503041913.j24JDfD8078029@khavrinen.lcs.mit.edu> Content-Type: text/plain Date: Fri, 04 Mar 2005 20:26:54 +0100 Message-Id: <1109964414.701.22.camel@notebook.bachi.net> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: xsocket unique id X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 04 Mar 2005 19:26:58 -0000 > > my question is: which variable in the xsocket or socket structure, is the > > unique id of a socket? > > xso_so hmmm... i think, it's not a number, but a socket structure. is this effectively the unique id? greets Andreas Bachmann From owner-freebsd-net@FreeBSD.ORG Fri Mar 4 19:41:34 2005 Return-Path: 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 BDA9E16A4CE; Fri, 4 Mar 2005 19:41:34 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B26943D2D; Fri, 4 Mar 2005 19:41:34 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 3A5E37A41E; Fri, 4 Mar 2005 11:41:34 -0800 (PST) Message-ID: <4228B9ED.9040906@elischer.org> Date: Fri, 04 Mar 2005 11:41:33 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: Aziz KEZZOU References: <37e13166050304080715525d7e@mail.gmail.com> In-Reply-To: <37e13166050304080715525d7e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: hackers@freebsd.org Subject: Re: generic network protocols parser ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 04 Mar 2005 19:41:34 -0000 Aziz KEZZOU wrote: >Hi all, >I am wondering if any one knows about a generic parser which takes a >packet (mbuf) of a certain protocol (e.g RSVP ) as input and generates >some data structre representing the packet ? > > you might look at DPF (a packet filter/classifier).. it has an interesting filter description language. >I've been searching for a while and found that ethereal and tcpdump >for example use specific data structres and functions to dissect each >protocol packets. Is this the only approach possible ? > >My supervisor suggested using a TLV (Type/Length/Value) approach >instead. Any opinions about that? > >If no such a parser exists is there any practical reason why ? > >Thanks, >Aziz >_______________________________________________ >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 Mar 4 20:05:00 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 40DFC16A4CE; Fri, 4 Mar 2005 20:05:00 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.3/8.13.1) with ESMTP id j24K4xTm076678; Fri, 4 Mar 2005 15:04:59 -0500 (EST) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.3/8.13.1/Submit) id j24K4xXT076677; Fri, 4 Mar 2005 15:04:59 -0500 (EST) (envelope-from green) Date: Fri, 4 Mar 2005 15:04:58 -0500 From: Brian Fundakowski Feldman To: Aziz KEZZOU Message-ID: <20050304200458.GG6011@green.homeunix.org> References: <37e13166050304080715525d7e@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37e13166050304080715525d7e@mail.gmail.com> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org cc: hackers@freebsd.org Subject: Re: generic network protocols parser ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 04 Mar 2005 20:05:00 -0000 On Fri, Mar 04, 2005 at 11:07:34AM -0500, Aziz KEZZOU wrote: > Hi all, > I am wondering if any one knows about a generic parser which takes a > packet (mbuf) of a certain protocol (e.g RSVP ) as input and generates > some data structre representing the packet ? > > I've been searching for a while and found that ethereal and tcpdump > for example use specific data structres and functions to dissect each > protocol packets. Is this the only approach possible ? > > My supervisor suggested using a TLV (Type/Length/Value) approach > instead. Any opinions about that? > > If no such a parser exists is there any practical reason why ? Ethereal uses TLV... -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-net@FreeBSD.ORG Fri Mar 4 22:08:10 2005 Return-Path: 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 5A9B216A4CE; Fri, 4 Mar 2005 22:08:10 +0000 (GMT) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA44843D2D; Fri, 4 Mar 2005 22:08:09 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id ED9C8CFAD; Fri, 4 Mar 2005 17:08:08 -0500 (EST) Received: by canoe.dclg.ca (Postfix, from userid 101) id DC2EF1A0991; Fri, 4 Mar 2005 17:08:05 -0500 (EST) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16936.56389.812572.568326@canoe.dclg.ca> Date: Fri, 4 Mar 2005 17:08:05 -0500 To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid Subject: quagga and OSPFD and point-to-point tunnels. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 04 Mar 2005 22:08:10 -0000 Here is an odd situation. If I start quagga ospfd after creating gre, tun, or gif devices, ospfd recognises them as point-to-point interfaces and everything works. However, if I start quagga and then create interfaces afterwards, the interfaces are not recognised as point-to-point interfaces and OSPF packets only travel in one direction (into the box). I'm not sure if the problem lies solely with quagga or FreeBSD or a little of both. For one, does the GRE device not have the POINTOPOINT flag set immediately? Has someone banged their head against this problem? It appears to cover all versions of FreeBSD, but I'm using 5.3-RELEASE-p5 to test. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-net@FreeBSD.ORG Fri Mar 4 22:34:42 2005 Return-Path: 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 6380F16A4CE for ; Fri, 4 Mar 2005 22:34:42 +0000 (GMT) Received: from angryfist.fasttrackmonkey.com (angryfist.fasttrackmonkey.com [216.223.196.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A19C643D2D for ; Fri, 4 Mar 2005 22:34:39 +0000 (GMT) (envelope-from spork@fasttrackmonkey.com) Received: (qmail 88522 invoked by uid 2003); 4 Mar 2005 22:29:09 -0000 Received: from spork@fasttrackmonkey.com by angryfist.fasttrackmonkey.com by uid 1001 with qmail-scanner-1.20 (clamscan: 0.65. Clear:RC:1(216.220.116.154):. Processed in 0.239148 secs); 04 Mar 2005 22:29:09 -0000 Received: from unknown (HELO localhost) (216.220.116.154) by 0 with (DHE-RSA-AES256-SHA encrypted) SMTP; 4 Mar 2005 22:29:08 -0000 Date: Fri, 4 Mar 2005 17:34:35 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@oof.local To: freebsd-net@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: FreeBSD 4.x and OS-X tcp performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 04 Mar 2005 22:34:42 -0000 Howdy, Sorry to bring what seems like a simple issue up here. I had been blaming slow afp filesharing between my OS-X (10.3.8 and previous) and FreeBSD 4.x boxes on netatalk's afp implementation for some time. Not too long ago I got frustrated with this and tried smb and then ftp. On a simple 10/100 network, and even with just a crossover between two boxes it seems that any tcp transfer tops out at around 250KB/s. On the same network using the same switch I can get near line-rate to an OpenBSD box and to another OS-X box. If I use nfs and force udp as the transport, I *do* get near line-rate between OS-X and FBSD. My 5.3 box is tanked at the moment, so I cannot tell if the problem happens there as well. I do have a full ADC account, so I will be testing with the latest Tiger preview shortly, and the ADC access does give me a decent bug reporting facility if the fault lies within the OS-X tcp stack. I'm no tcpdump wizard, would anyone care to help me track this down? Thanks, Charles From owner-freebsd-net@FreeBSD.ORG Fri Mar 4 23:25:47 2005 Return-Path: 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 9F27816A4D0 for ; Fri, 4 Mar 2005 23:25:47 +0000 (GMT) Received: from mail2.dbitech.ca (radius.wavefire.com [64.141.13.252]) by mx1.FreeBSD.org (Postfix) with SMTP id E720E43D48 for ; Fri, 4 Mar 2005 23:25:46 +0000 (GMT) (envelope-from darcy@wavefire.com) Received: (qmail 14137 invoked from network); 5 Mar 2005 00:52:51 -0000 Received: from unknown (HELO ?64.141.15.12?) (64.141.15.12) by radius.wavefire.com with SMTP; 5 Mar 2005 00:52:51 -0000 From: Darcy Buskermolen Organization: Wavefire Technologies Corp To: freebsd-net@freebsd.org Date: Fri, 4 Mar 2005 15:26:05 -0800 User-Agent: KMail/1.7.2 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503041526.05432.darcy@wavefire.com> cc: Charles Sprickman Subject: Re: FreeBSD 4.x and OS-X tcp performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 04 Mar 2005 23:25:47 -0000 On Friday 04 March 2005 14:34, Charles Sprickman wrote: > Howdy, > > Sorry to bring what seems like a simple issue up here. I had been blaming > slow afp filesharing between my OS-X (10.3.8 and previous) and FreeBSD 4.x > boxes on netatalk's afp implementation for some time. Not too long ago I > got frustrated with this and tried smb and then ftp. On a simple 10/100 > network, and even with just a crossover between two boxes it seems that > any tcp transfer tops out at around 250KB/s. > > On the same network using the same switch I can get near line-rate to an > OpenBSD box and to another OS-X box. > > If I use nfs and force udp as the transport, I *do* get near line-rate > between OS-X and FBSD. > > My 5.3 box is tanked at the moment, so I cannot tell if the problem > happens there as well. I do have a full ADC account, so I will be testing > with the latest Tiger preview shortly, and the ADC access does give me a > decent bug reporting facility if the fault lies within the OS-X tcp stack. > > I'm no tcpdump wizard, would anyone care to help me track this down? I'd start with ensureing your nic's media options are properly set (I've seen this exact behavior during duplex mismatches) > > Thanks, > > Charles > _______________________________________________ > 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 Mar 4 23:43:46 2005 Return-Path: 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 604F816A4CE for ; Fri, 4 Mar 2005 23:43:46 +0000 (GMT) Received: from angryfist.fasttrackmonkey.com (angryfist.fasttrackmonkey.com [216.223.196.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93FA143D4C for ; Fri, 4 Mar 2005 23:43:45 +0000 (GMT) (envelope-from spork@fasttrackmonkey.com) Received: (qmail 89991 invoked by uid 2003); 4 Mar 2005 23:38:16 -0000 Received: from spork@fasttrackmonkey.com by angryfist.fasttrackmonkey.com by uid 1001 with qmail-scanner-1.20 (clamscan: 0.65. Clear:RC:1(216.220.116.154):. Processed in 0.151734 secs); 04 Mar 2005 23:38:16 -0000 Received: from unknown (HELO localhost) (216.220.116.154) by 0 with (DHE-RSA-AES256-SHA encrypted) SMTP; 4 Mar 2005 23:38:15 -0000 Date: Fri, 4 Mar 2005 18:43:43 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@oof.local To: Darcy Buskermolen In-Reply-To: <200503041526.05432.darcy@wavefire.com> Message-ID: References: <200503041526.05432.darcy@wavefire.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 4.x and OS-X tcp performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 04 Mar 2005 23:43:46 -0000 On Fri, 4 Mar 2005, Darcy Buskermolen wrote: > On Friday 04 March 2005 14:34, Charles Sprickman wrote: >> Howdy, >> >> Sorry to bring what seems like a simple issue up here. I had been blaming >> slow afp filesharing between my OS-X (10.3.8 and previous) and FreeBSD 4.x >> boxes on netatalk's afp implementation for some time. Not too long ago I >> got frustrated with this and tried smb and then ftp. On a simple 10/100 >> network, and even with just a crossover between two boxes it seems that >> any tcp transfer tops out at around 250KB/s. >> >> On the same network using the same switch I can get near line-rate to an >> OpenBSD box and to another OS-X box. >> >> If I use nfs and force udp as the transport, I *do* get near line-rate >> between OS-X and FBSD. >> >> My 5.3 box is tanked at the moment, so I cannot tell if the problem >> happens there as well. I do have a full ADC account, so I will be testing >> with the latest Tiger preview shortly, and the ADC access does give me a >> decent bug reporting facility if the fault lies within the OS-X tcp stack. >> >> I'm no tcpdump wizard, would anyone care to help me track this down? > > I'd start with ensureing your nic's media options are properly set (I've seen > this exact behavior during duplex mismatches) Yep, I wouldn't have come here without checking all the basics. I should also add that given three machines in my standard config I get the following results which will also help rule out cabling/speed/duplex issues: os-x <-> obsd - good os-x <-> fbsd - bad obsd <-> fbsd - good os-x <-> os-x - good Charles >> Thanks, >> >> Charles >> _______________________________________________ >> 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 Sat Mar 5 00:14:03 2005 Return-Path: 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 1B4BE16A4CE for ; Sat, 5 Mar 2005 00:14:03 +0000 (GMT) Received: from imf20aec.mail.bellsouth.net (imf20aec.mail.bellsouth.net [205.152.59.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A7A243D41 for ; Sat, 5 Mar 2005 00:14:02 +0000 (GMT) (envelope-from lists@elhombre.us) Received: from [192.168.0.10] ([67.32.198.253]) by imf20aec.mail.bellsouth.netESMTP <20050305001401.QYTA1995.imf20aec.mail.bellsouth.net@[192.168.0.10]>; Fri, 4 Mar 2005 19:14:01 -0500 In-Reply-To: References: <200503041526.05432.darcy@wavefire.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dustin Wilhoit Date: Fri, 4 Mar 2005 18:14:00 -0600 To: Charles Sprickman X-Mailer: Apple Mail (2.619.2) cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 4.x and OS-X tcp performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 05 Mar 2005 00:14:03 -0000 On Mar 4, 2005, at 5:43 PM, Charles Sprickman wrote: > Yep, I wouldn't have come here without checking all the basics. I > should also add that given three machines in my standard config I get > the following results which will also help rule out > cabling/speed/duplex issues: > os-x <-> obsd - good > os-x <-> fbsd - bad > obsd <-> fbsd - good > os-x <-> os-x - good > > Charles This doesn't rule out duplex for the OS X <-> FBSD line. Hard set them both and test, again it's a suggestion but because it'll autoconfig right on the others doesn't mean it is on that particular one. Dustin W. From owner-freebsd-net@FreeBSD.ORG Sat Mar 5 02:49:05 2005 Return-Path: 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 69D6416A4CE for ; Sat, 5 Mar 2005 02:49:05 +0000 (GMT) Received: from wjv.com (fl-65-40-24-38.sta.sprint-hsd.net [65.40.24.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADAE043D2D for ; Sat, 5 Mar 2005 02:49:04 +0000 (GMT) (envelope-from bv@bilver.wjv.com) Received: from bilver.wjv.com (localhost.wjv.com [127.0.0.1]) by wjv.com (8.12.11/8.13.1) with ESMTP id j252mqoG038397; Fri, 4 Mar 2005 21:48:52 -0500 (EST) (envelope-from bv@bilver.wjv.com) Received: (from bv@localhost) by bilver.wjv.com (8.12.11/8.13.1/Submit) id j252mpWw038178; Fri, 4 Mar 2005 21:48:51 -0500 (EST) (envelope-from bv) Date: Fri, 4 Mar 2005 21:48:50 -0500 From: Bill Vermillion To: Charles Sprickman Message-ID: <20050305024850.GA96307@wjv.com> References: <200503041526.05432.darcy@wavefire.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: W.J.Vermillion / Orlando - Winter Park ReplyTo: bv@wjv.com User-Agent: Mutt/1.5.6i X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on bilver.wjv.com cc: freebsd-net@freebsd.org cc: Darcy Buskermolen Subject: Re: FreeBSD 4.x and OS-X tcp performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: bv@wjv.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 02:49:05 -0000 "Ang utong ko ay sasabog sa sarap!" exclaimed Charles Sprickman while reading this message on Fri, Mar 04, 2005 at 18:43 and then responded with: > On Fri, 4 Mar 2005, Darcy Buskermolen wrote: > >On Friday 04 March 2005 14:34, Charles Sprickman wrote: > >>Howdy, > >>Sorry to bring what seems like a simple issue up here. > >>I had been blaming slow afp filesharing between my OS-X > >>(10.3.8 and previous) and FreeBSD 4.x boxes on netatalk's > >>afp implementation for some time. Not too long ago I got > >>frustrated with this and tried smb and then ftp. On a simple > >>10/100 network, and even with just a crossover between two > >>boxes it seems that any tcp transfer tops out at around > >>250KB/s. > >>On the same network using the same switch I can get near > >>Oline-rate to an penBSD box and to another OS-X box. > >>If I use nfs and force udp as the transport, I *do* get near > >>line-rate between OS-X and FBSD. > >>My 5.3 box is tanked at the moment, so I cannot tell if the > >>problem happens there as well. I do have a full ADC account, > >>so I will be testing with the latest Tiger preview shortly, > >>and the ADC access does give me a decent bug reporting > >>facility if the fault lies within the OS-X tcp stack. > >>I'm no tcpdump wizard, would anyone care to help me track this down? > >I'd start with ensureing your nic's media options are properly > >set (I've seen this exact behavior during duplex mismatches) > Yep, I wouldn't have come here without checking all the basics. I should > also add that given three machines in my standard config I get the > following results which will also help rule out cabling/speed/duplex > issues: > os-x <-> obsd - good > os-x <-> fbsd - bad > obsd <-> fbsd - good > os-x <-> os-x - good I've seen this before. A client had three OS/X machines in our rack, one standard G4 and two Xrack devices. One had severe problems connecting withour FreeBSD machines but not to others. I was never able to get with him in an interactive mode to check things. He said he'd tried different settings but never got with me when he was doing this so that I could check his machine, our machine, and the intermediate switch. He moved out to a rack of his own so I never did find out what was wrong. I do suspect duplex problems. He was connecting to one of our Cicso switches and Cisco has some extensive docs on some configuration problems. Part of it comes from when some vendors decided to add their own features and violated standards. http://www.cisco.com/warp/public/473/46.html This is the link I saved from awhile back. I hope it is still valid. But problems like this usually come from one side or the other not properly responding to auto-negotiation as documented. When auto-neg fails at least one side will go to half-duplex, and with the other in fdx then you usually only see throughput of about 10% of normal because of data being sent back on a line that the fdx line thinks is clear to send upon. Bill -- Bill Vermillion - bv @ wjv . com