From owner-freebsd-net@FreeBSD.ORG Sun Aug 3 08:06:01 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B9681065675 for ; Sun, 3 Aug 2008 08:06:01 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outQ.internet-mail-service.net (outq.internet-mail-service.net [216.240.47.240]) by mx1.freebsd.org (Postfix) with ESMTP id 8634F8FC15 for ; Sun, 3 Aug 2008 08:06:01 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id A5BDD2476; Sun, 3 Aug 2008 01:06:01 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id EEFAB2D60CD; Sun, 3 Aug 2008 01:06:00 -0700 (PDT) Message-ID: <489566F5.9040308@elischer.org> Date: Sun, 03 Aug 2008 01:06:13 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: FreeBSD Net , freebsd-virtualization@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Developers adding global variables. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2008 08:06:01 -0000 If you are adding globals to the networking code, (or if you have added soem globals in the last few months, could you make sure that I am aware of them? marko Zec and I are trying to keep teh Vimage tree in perforce in sync with -current but there is noo automatic way that we would be noticfied of the sudden appearance of a new global variable in the networking code. Today I noticed tcp_do_ecn and tcp_ecn_maxretries but only because of their proximity to another change. thanks Julian From owner-freebsd-net@FreeBSD.ORG Sun Aug 3 08:06:57 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CD661065674 for ; Sun, 3 Aug 2008 08:06:57 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (grosbein.pp.ru [89.189.172.146]) by mx1.freebsd.org (Postfix) with ESMTP id 9BFAE8FC1A for ; Sun, 3 Aug 2008 08:06:56 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (localhost [127.0.0.1]) by grosbein.pp.ru (8.14.2/8.14.2) with ESMTP id m737c47N010353 for ; Sun, 3 Aug 2008 15:38:04 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.14.2/8.14.2/Submit) id m737c3O3010352 for net@freebsd.org; Sun, 3 Aug 2008 15:38:03 +0800 (KRAST) (envelope-from eugen) Date: Sun, 3 Aug 2008 15:38:03 +0800 From: Eugene Grosbein To: net@freebsd.org Message-ID: <20080803073803.GA10321@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: permissions on /etc/namedb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2008 08:06:57 -0000 Hi! I need /etc/namedb to be owned by root:bind and have permissions 01775, so bind may write to it but may not overwrite files that belong to root here, and I made it so. Suprise! # /etc/rc.d/named restart Stopping named. Waiting for PIDS: 1892. etc/namedb changed gid expected 0 found 53 modified permissions expected 0755 found 01775 modified Starting named. I dislike it very much when a system thinks it knows better what user needs. Also, I do not want to move a place where bind writes its files to another location just because system does not want it to write here. Why was this done such way, do I miss something? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sun Aug 3 08:21:45 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C982A1065697 for ; Sun, 3 Aug 2008 08:21:45 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 4811B8FC0A for ; Sun, 3 Aug 2008 08:21:45 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so2149443fgb.35 for ; Sun, 03 Aug 2008 01:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=BISRZ5UBMPDyLnqIzNe6hRbvEIiwcSJl4UbiW18CAYI=; b=KWVierMP75UqdwbD1rC/7H6vPOjDr7as+/7ULZdl1+0PZQw6PyP6uMPkU6eIbvq3rF YBIcoQt4Hx4whgCVxcF5n+7Yt1Do9T7Na6JelHV/y+KarAbW7xuSoU6nTNe5Z2wu2ERp 0sX+zwuQYfHyRNMENAzoug2LSdYX1sZmibnjs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=ulOpnKRY8ntp7gByqthmhYmq558+Ig3EimNzhxOLme/lHvFzr3D6124HWbWDYjGFuB gdC4lK3SoyRKzZYpmaTFWjLsqcCsxclG3+gW/VdAUTNVNYs0Pe+oBMWopri/GCB0e76h 84M2SgvZutwXCfn1xHJ8rQrt3VvCVWbhwM6Nw= Received: by 10.86.74.15 with SMTP id w15mr9216614fga.8.1217751704022; Sun, 03 Aug 2008 01:21:44 -0700 (PDT) Received: from ?192.168.5.4? ( [78.107.233.167]) by mx.google.com with ESMTPS id d6sm4126523fga.2.2008.08.03.01.21.41 (version=SSLv3 cipher=RC4-MD5); Sun, 03 Aug 2008 01:21:42 -0700 (PDT) Message-ID: <48956A7C.90107@gmail.com> Date: Sun, 03 Aug 2008 12:21:16 +0400 From: Vladimir Ermakov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.13) Gecko/20080708 SeaMonkey/1.1.9 MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: problem with iwn interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2008 08:21:45 -0000 Hello My problem appears when using the |net-p2p/qbittorrent| for downloading media-data from the torrent trackers. here are some outputs ---------------------------------------------------------------------- # uname -a FreeBSD spectrum 7.0-STABLE FreeBSD 7.0-STABLE #0: Fri Jul 18 22:39:18 MSD 2008 root@spectrum:/usr/obj/usr/src/sys/SPECTRUM i386 ---------------------------------------------------------------------- ---------------------------------------------------------------------- Aug 3 11:39:31 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 62 Aug 3 11:39:31 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 62 Aug 3 11:39:31 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 63 Aug 3 11:39:31 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 65 Aug 3 11:39:31 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 62 Aug 3 11:39:31 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 64 Aug 3 11:39:32 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 66 Aug 3 11:39:32 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 64 Aug 3 11:39:32 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 65 Aug 3 11:39:32 spectrum last message repeated 2 times Aug 3 11:39:32 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 67 Aug 3 11:39:32 spectrum kernel: iwn0: error, INTR=2000000 STATUS=0x0 ---------------------------------------------------------------------- ---------------------------------------------------------------------- 64 bytes from 213.180.204.8: icmp_seq=718 ttl=57 time=124.113 ms 64 bytes from 213.180.204.8: icmp_seq=719 ttl=57 time=100.074 ms 64 bytes from 213.180.204.8: icmp_seq=720 ttl=57 time=107.891 ms 64 bytes from 213.180.204.8: icmp_seq=721 ttl=57 time=136.788 ms 64 bytes from 213.180.204.8: icmp_seq=722 ttl=57 time=149.726 ms 64 bytes from 213.180.204.8: icmp_seq=723 ttl=57 time=129.400 ms ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ---------------------------------------------------------------------- ---------------------------------------------------------------------- iwn0: flags=8c43 metric 0 mtu 1500 ether 00:1d:e0:9b:b0:86 inet 192.168.1.4 netmask 0xffffff00 broadcast 192.168.1.255 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/54Mbps) status: associated ssid cargo channel 7 (2442 Mhz 11g) bssid 00:12:6b:63:17:10 authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit txpower 50 bmiss 10 scanvalid 60 protmode CTS roaming MANUAL ---------------------------------------------------------------------- please, any solutions? /Vladimir Ermakov From owner-freebsd-net@FreeBSD.ORG Sun Aug 3 08:32:24 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 688E51065679 for ; Sun, 3 Aug 2008 08:32:24 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id DC2328FC15 for ; Sun, 3 Aug 2008 08:32:23 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so2152472fgb.35 for ; Sun, 03 Aug 2008 01:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=BISRZ5UBMPDyLnqIzNe6hRbvEIiwcSJl4UbiW18CAYI=; b=cfjXxepMs3mQ5++fSVPPcZgn26VMFUDGQ6AhSMVWFOuhk5cw+zJyXG/Sz0IoVOqGyZ ZmnBupyIPEHPpjeP6UitDL1s92KkSi3B7RGbhWWvDjELZEsC9mw206tsRxHXDo3OcAi+ afdgFYB28pNJ/hcp17EQgCL+ADADp0Y0XRa8g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=Fx1jjwMN/tISlQXftw5OVKPS+hsm3Pk1RaU6w5mPqe9qfHqu3Jqzsktwb+pzIm6cwv ZCTWkj49+dpoUraS74eT6ZhSiamUMOT/p/sSCJsjKeSYnrIIXuPZFDgM3vrQFYEeoJxK O/FnPic0DHLZravErmKhBwLrfp7vstmRKoBcg= Received: by 10.86.74.15 with SMTP id w15mr9213824fga.13.1217750757042; Sun, 03 Aug 2008 01:05:57 -0700 (PDT) Received: from ?192.168.5.4? ( [78.107.233.167]) by mx.google.com with ESMTPS id 4sm2281502fgg.4.2008.08.03.01.05.54 (version=SSLv3 cipher=RC4-MD5); Sun, 03 Aug 2008 01:05:55 -0700 (PDT) Message-ID: <489566C9.8040406@gmail.com> Date: Sun, 03 Aug 2008 12:05:29 +0400 From: Vladimir Ermakov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.13) Gecko/20080708 SeaMonkey/1.1.9 MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: iwn0: received beacon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2008 08:32:24 -0000 Hello My problem appears when using the |net-p2p/qbittorrent| for downloading media-data from the torrent trackers. here are some outputs ---------------------------------------------------------------------- # uname -a FreeBSD spectrum 7.0-STABLE FreeBSD 7.0-STABLE #0: Fri Jul 18 22:39:18 MSD 2008 root@spectrum:/usr/obj/usr/src/sys/SPECTRUM i386 ---------------------------------------------------------------------- ---------------------------------------------------------------------- Aug 3 11:39:31 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 62 Aug 3 11:39:31 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 62 Aug 3 11:39:31 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 63 Aug 3 11:39:31 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 65 Aug 3 11:39:31 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 62 Aug 3 11:39:31 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 64 Aug 3 11:39:32 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 66 Aug 3 11:39:32 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 64 Aug 3 11:39:32 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 65 Aug 3 11:39:32 spectrum last message repeated 2 times Aug 3 11:39:32 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 67 Aug 3 11:39:32 spectrum kernel: iwn0: error, INTR=2000000 STATUS=0x0 ---------------------------------------------------------------------- ---------------------------------------------------------------------- 64 bytes from 213.180.204.8: icmp_seq=718 ttl=57 time=124.113 ms 64 bytes from 213.180.204.8: icmp_seq=719 ttl=57 time=100.074 ms 64 bytes from 213.180.204.8: icmp_seq=720 ttl=57 time=107.891 ms 64 bytes from 213.180.204.8: icmp_seq=721 ttl=57 time=136.788 ms 64 bytes from 213.180.204.8: icmp_seq=722 ttl=57 time=149.726 ms 64 bytes from 213.180.204.8: icmp_seq=723 ttl=57 time=129.400 ms ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ---------------------------------------------------------------------- ---------------------------------------------------------------------- iwn0: flags=8c43 metric 0 mtu 1500 ether 00:1d:e0:9b:b0:86 inet 192.168.1.4 netmask 0xffffff00 broadcast 192.168.1.255 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/54Mbps) status: associated ssid cargo channel 7 (2442 Mhz 11g) bssid 00:12:6b:63:17:10 authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit txpower 50 bmiss 10 scanvalid 60 protmode CTS roaming MANUAL ---------------------------------------------------------------------- please, any solutions? /Vladimir Ermakov From owner-freebsd-net@FreeBSD.ORG Sun Aug 3 10:32:17 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86E4E1065677; Sun, 3 Aug 2008 10:32:17 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5D5568FC12; Sun, 3 Aug 2008 10:32:17 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id B388C46B5C; Sun, 3 Aug 2008 06:32:16 -0400 (EDT) Date: Sun, 3 Aug 2008 11:32:16 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <489566F5.9040308@elischer.org> Message-ID: References: <489566F5.9040308@elischer.org> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Net , freebsd-virtualization@freebsd.org Subject: Re: Developers adding global variables. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2008 10:32:17 -0000 On Sun, 3 Aug 2008, Julian Elischer wrote: > If you are adding globals to the networking code, (or if you have added soem > globals in the last few months, could you make sure that I am aware of them? > > marko Zec and I are trying to keep teh Vimage tree in perforce in sync with > -current but there is noo automatic way that we would be noticfied of the > sudden appearance of a new global variable in the networking code. > > Today I noticed tcp_do_ecn and tcp_ecn_maxretries but only because of their > proximity to another change. While not a universal solution, one technique you could use to catch things like this is to compare the set of symbols in a !virtualization kernel with those in a virtualization kernels, perhaps using nm(1), and compare that difference set over time. Not perfect, but it would allow you to look for things that have been missed. FWIW, I have no immediate plans to add any global variables to the network stack. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Sun Aug 3 13:05:44 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C861106564A for ; Sun, 3 Aug 2008 13:05:44 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id D00DE8FC15 for ; Sun, 3 Aug 2008 13:05:41 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id WAA18657; Sun, 3 Aug 2008 22:32:23 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 3 Aug 2008 22:32:22 +1000 (EST) From: Ian Smith To: Eugene Grosbein In-Reply-To: <20080803073803.GA10321@grosbein.pp.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: net@freebsd.org Subject: Re: permissions on /etc/namedb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2008 13:05:44 -0000 On Sun, 3 Aug 2008, Eugene Grosbein wrote: > I need /etc/namedb to be owned by root:bind and have permissions 01775, > so bind may write to it but may not overwrite files that belong to root > here, and I made it so. Suprise! > > # /etc/rc.d/named restart > Stopping named. > Waiting for PIDS: 1892. > etc/namedb changed > gid expected 0 found 53 modified > permissions expected 0755 found 01775 modified > Starting named. Are you running /etc/namedb linked to chroot'd /var/named/etc/namedb? If so, that'd be mtree restoring perms from /etc/mtree/BIND.chroot.dist I couldn't get rndc trace running to named.run for ages, same problem: bind user couldn't write to (default) /var/named/etc/namedb/named.run unless it already existed, owned by bind. Added to /etc/rc.d/named: touch /var/named/etc/namedb/named.run chown bind /var/named/etc/namedb/named.run # bind:wheel 644 and now trace and querylog are happy, so I am. Running latest 5-STABLE here but I see no changes in 7 or HEAD cvs related to this. Suppose I should do up a PR with a patch, unless someone knows a better way? I don't know if this helps with whatever file/s you want bind to write, or whether there are other files bind writes needing similar treatment. > I dislike it very much when a system thinks it knows better what user needs. > Also, I do not want to move a place where bind writes its files to another > location just because system does not want it to write here. > Why was this done such way, do I miss something? I'm usually glad that FreeBSD's bind setup tends to paranoia :) cheers, Ian From owner-freebsd-net@FreeBSD.ORG Sun Aug 3 13:44:16 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 138A0106568A for ; Sun, 3 Aug 2008 13:44:16 +0000 (UTC) (envelope-from mtm@wubethiopia.com) Received: from dire.wubethiopia.com (j071.v.rootbsd.net [208.79.82.223]) by mx1.freebsd.org (Postfix) with ESMTP id CA1938FC15 for ; Sun, 3 Aug 2008 13:44:15 +0000 (UTC) (envelope-from mtm@wubethiopia.com) Received: from rogue.mike.lan (unknown [213.55.65.140]) by dire.wubethiopia.com (Postfix) with ESMTPSA id 45F184FDA214; Sun, 3 Aug 2008 13:44:09 +0000 (UTC) Message-ID: <4895B799.6070508@wubethiopia.com> Date: Sun, 03 Aug 2008 16:50:17 +0300 From: Mike Makonnen User-Agent: Thunderbird 2.0.0.12 (X11/20080323) MIME-Version: 1.0 To: Ian Smith References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Patrick Tracanelli , freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2008 13:44:16 -0000 Ian Smith wrote: > On Fri, 1 Aug 2008, Mike Makonnen wrote: > > Patrick Tracanelli wrote: > > > Mike Makonnen escreveu: > > >> Hi, > > >> > > >> An Internet Cafe I do some work for was recently having problems with > > >> very slow internet access. It turns out customers were running P2P > > >> file sharing applications which were hogging all the bandwidth. I > > >> looked for programs that would allow me to shape traffic according > > >> to the application layer protocol, but couldn't find any for FreeBSD. > > >> I found a couple: l7-filter and ipp2p, but these are Linux specific. > > >> So, I decided to write one. The result is ipfw-classifyd : > > >> http://people.freebsd.org/~mtm/ipfw-classifyd.tar.bz2 > > This is great, Mike. I've been 'waiting for this' for a very similar > situation for months now, getting by with dummynet bandwidth limiting > and wondering about weighted queuing, but this is a much sharper tool. > > > >> As the name implies it uses ipfw(4) to implement a userland daemon > > >> that classifies TCP and UDP packets according to regular expression > > >> patterns for various protocols. It's intended to be used with > > >> divert(4) sockets and dummynet(4) so you can do traffic shaping > > >> depending on the application level protocol. The protocol patterns > > >> are from the l7-filter project. > > Any GPL issues with using these patterns? > I don't believe so. > > >> Basically, you use ipfw(8) to divert tcp/udp packets to the damon. It > > >> reads its configuration file for a list of protocols and ipfw(8) > > >> rules. Then, when it detects a matching session it re-injects the > > >> packet back at the specified rule number. The tarball has a sample > > >> configuration file and firewall script to get you started. > > I was confused by 'back at the specified rule number' too, especially as > you used a rule 1000 in the example, being the rule handling NON matched > packets. So I had a browse through the code, finding: > > /* > * Inform divert(4) what rule to send it to by > * modifying the port number of the associated sockaddr_in > * structure. Note: we subtract one from the ipfw(4) rule > * number because processing in ipfw(4) will start with > * the next rule *after* the supplied rule number. > */ > if (flow->if_fwrule != 0) { > pkt->fp_saddr.sin_port = flow->if_fwrule; > goto enqueue; > } > > and noticed that we weren't subtracting one .. > The comment is wrong. It was for a prior version of the code. Initially, I had the configuration file specify the rule number that passes the diverted packets to dummynet(4). The code (as the comment says) would subtract 1 from the number when it wrote the packet back, but I wasn't sure how ipfw(4) would react to a possibly non-existant rule so changed it to its current form. However, after thinking about it some more I think it is more intuitive and easier to understand if the configuration file specified the rule that passes the diverted packet to the pipe or queue. > I don't believe it's quite correct to say 'ipfw will start with the next > rule after the supplied rule number'. If there were (legitimately) > multiple rules having the same number (either divert rules themselves or > at the target rule), the ipfw divert-return code skips past duplicates > to the next rule that has a higher rule number, which may not amount to > the same thing. > > (Sorry, Julian made me study ipfw execution behaviour months ago :) > > I thought at first that this behaviour is fine, and just needed a bit > better describing. But I'm starting to wonder if subtracting one isn't > really a better idea? > I'm leaning in the same direction. > > >> While I have not done extensive testing, preliminary tests are > > >> encouraging and it seems to work, so I thought I'd announce it to the > > >> rest of the world in case anyone else is interested in this kind of > > >> application. > > >> > > >> Comments and suggestions highly appreciated. > > >> > > >> Cheers. > > > > > > Wont compile on RELENG_6 but is working perfectly on REL_7. I am > > > trying hard with ssh, soulseek and msn. Its working like a charm with > > > the suggested rc.firewall. > > Can you email me the compile error? > > I'd like to run it on a 4.8 filtering bridge .. ah, never mind :) > > > > I have configured ipfw-classfyd.conf changing the rules, for a number > > > of L7 patterns, and now I try to understand why the "diverted" rules > > > only match if the rule number is 1 after the configured, ie, I put > > > soulseek to 65530 and a rule wont match there, but the very same rule > > > matches 65531. I will read the code, but it seems that reinjection of > > > the packet is made +1, correct? > > > > > The application doesn't do that, it's the firewall that does that. > > Basically, when > > ipfw(4) diverts a packet to the application it includes the rule > > that caused the packet to be diverted (so that when it gets it back it knows > > where to continue processing from). When it gets the packet back it > > continues > > processing the packet at the rule *after* the one that caused it to be > > diverted > > Rather, 'at the first rule having a higher rule number than the one ..' > > > (otherwise the packet would get diverted in an endless loop). In the sample > > script rule 1000 is the rule that passes the packets that do not get > > diverted, so > > I configured ipfw-classifyd to modify the information that comes with the > > packet to point to rule 1000 (in classifyd.conf). So, when ipfw(4) gets the > > packet back it continues processing it at the next rule after 1000, which is > > the rule that sends all diverted packets through the pipe. > > Yeah figuring out how rule 1000 had anything to do with it confused me > at first, when any number after the divert rule/s would do. I think it > may need stating really explicitly, something perhaps better put than: > > The rule number configured for the specified traffic type is that of > the last rule number *before* the target ipfw rule for a match. > > Which is still harder to describe (or get one's head around) than being > able to specify the desired target rule number in the config file? > > As long as you don't subtract one for the non-match packets reinjected > normally, and do subtract one from the matching packet's config rule, > so directly skipping to the specified rule, it would need an awful lot > less explaining to users .. > > > Hope that helps. > > Oh yes :) Might even have to upgrade that bridge at long last. > > Glad to hear people are finding it useful :-) Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Sun Aug 3 15:20:41 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 510C41065686 for ; Sun, 3 Aug 2008 15:20:41 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id A58128FC17 for ; Sun, 3 Aug 2008 15:20:40 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m73ElKYa034411; Sun, 3 Aug 2008 22:47:20 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m73ElJi7034409; Sun, 3 Aug 2008 22:47:19 +0800 (KRAST) (envelope-from eugen) Date: Sun, 3 Aug 2008 22:47:19 +0800 From: Eugene Grosbein To: Ian Smith Message-ID: <20080803144719.GA33577@svzserv.kemerovo.su> References: <20080803073803.GA10321@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: net@freebsd.org Subject: Re: permissions on /etc/namedb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2008 15:20:41 -0000 On Sun, Aug 03, 2008 at 10:32:22PM +1000, Ian Smith wrote: > > I need /etc/namedb to be owned by root:bind and have permissions 01775, > > so bind may write to it but may not overwrite files that belong to root > > here, and I made it so. Suprise! > > > > # /etc/rc.d/named restart > > Stopping named. > > Waiting for PIDS: 1892. > > etc/namedb changed > > gid expected 0 found 53 modified > > permissions expected 0755 found 01775 modified > > Starting named. > > Are you running /etc/namedb linked to chroot'd /var/named/etc/namedb? > If so, that'd be mtree restoring perms from /etc/mtree/BIND.chroot.dist I just have 'named_enable="YES"' in /etc/rc.conf, it's 6.3-STABLE and stock bind9. I could set named_chroot_autoupdate="NO", but I see now it won't mount devfs into chroot are in that case. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sun Aug 3 16:02:03 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 693421065674 for ; Sun, 3 Aug 2008 16:02:03 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 131308FC0A for ; Sun, 3 Aug 2008 16:02:01 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id CAA23962; Mon, 4 Aug 2008 02:01:19 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 4 Aug 2008 02:01:17 +1000 (EST) From: Ian Smith To: Eugene Grosbein In-Reply-To: <20080803144719.GA33577@svzserv.kemerovo.su> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: net@freebsd.org Subject: Re: permissions on /etc/namedb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2008 16:02:03 -0000 On Sun, 3 Aug 2008, Eugene Grosbein wrote: > On Sun, Aug 03, 2008 at 10:32:22PM +1000, Ian Smith wrote: > > > > I need /etc/namedb to be owned by root:bind and have permissions 01775, > > > so bind may write to it but may not overwrite files that belong to root > > > here, and I made it so. Suprise! > > > > > > # /etc/rc.d/named restart > > > Stopping named. > > > Waiting for PIDS: 1892. > > > etc/namedb changed > > > gid expected 0 found 53 modified > > > permissions expected 0755 found 01775 modified > > > Starting named. > > > > Are you running /etc/namedb linked to chroot'd /var/named/etc/namedb? > > If so, that'd be mtree restoring perms from /etc/mtree/BIND.chroot.dist > > I just have 'named_enable="YES"' in /etc/rc.conf, it's 6.3-STABLE > and stock bind9. I could set named_chroot_autoupdate="NO", > but I see now it won't mount devfs into chroot are in that case. So hacking /etc/rc.d/named in chroot_autoupdate to do something like: files_bind_writes='named.run' # whatever for f in ${files_bind_writes}; do touch ${named_chrootdir}/etc/namedb/${f} chown bind:wheel ${named_chrootdir}/etc/namedb/${f} done wouldn't work for you? cheers, Ian From owner-freebsd-net@FreeBSD.ORG Sun Aug 3 16:03:26 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BE73106566C; Sun, 3 Aug 2008 16:03:26 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 72D538FC17; Sun, 3 Aug 2008 16:03:26 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m73G3Qtg043747; Sun, 3 Aug 2008 16:03:26 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m73G3Q07043743; Sun, 3 Aug 2008 16:03:26 GMT (envelope-from remko) Date: Sun, 3 Aug 2008 16:03:26 GMT Message-Id: <200808031603.m73G3Q07043743@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: i386/126214: txpower problem with Atheros wifi card X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2008 16:03:26 -0000 Synopsis: txpower problem with Atheros wifi card Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Sun Aug 3 16:03:26 UTC 2008 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=126214 From owner-freebsd-net@FreeBSD.ORG Sun Aug 3 16:26:49 2008 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB68C106566C; Sun, 3 Aug 2008 16:26:49 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id AFC898FC08; Sun, 3 Aug 2008 16:26:49 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id AA20F46B51; Sun, 3 Aug 2008 12:26:48 -0400 (EDT) Date: Sun, 3 Aug 2008 17:26:48 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: net@FreeBSD.org, current@FreeBSD.org In-Reply-To: <20080630091033.P3968@fledge.watson.org> Message-ID: References: <20080524111715.T64552@fledge.watson.org> <20080629180126.F90836@fledge.watson.org> <20080630091033.P3968@fledge.watson.org> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org Subject: Re: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2008 16:26:50 -0000 On Mon, 30 Jun 2008, Robert Watson wrote: > On Sun, 29 Jun 2008, Robert Watson wrote: > >> An FYI on the state of things here: in the last month, John has updated a >> number of device drivers to be MPSAFE, and the USB work remains in-flight. >> I'm holding fire a bit on disabling IFF_NEEDSGIANT while things settle and >> I catch up on driver state, and will likely send out an update next week >> regarding which device drivers remain on the kill list, and generally what >> the status of this project is. > > Here's the revised list of drivers that will have their build disabled in > the next week (subject to an appropriate block of time for me): A quick update: I had postponed removing IFF_NEEDSGIANT while awaiting the apparently forthcoming USB stack commit. Since it appears slow in coming, I will move ahead and disconnect non-USB drivers that require IFF_NEEDSGIANT in the coming week, but will leave the IFF_NEEDSGIANT infrastructure there, along with the current USB drivers that depend on it, until the USB merge is done. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Sun Aug 3 16:56:21 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB364106564A for ; Sun, 3 Aug 2008 16:56:21 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 37AD28FC0C for ; Sun, 3 Aug 2008 16:56:20 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m73GuHeb046113; Mon, 4 Aug 2008 00:56:17 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m73GuHbb046112; Mon, 4 Aug 2008 00:56:17 +0800 (KRAST) (envelope-from eugen) Date: Mon, 4 Aug 2008 00:56:17 +0800 From: Eugene Grosbein To: Ian Smith Message-ID: <20080803165617.GA45778@svzserv.kemerovo.su> References: <20080803144719.GA33577@svzserv.kemerovo.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: net@freebsd.org Subject: Re: permissions on /etc/namedb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2008 16:56:21 -0000 > So hacking /etc/rc.d/named in chroot_autoupdate to do something like: > > files_bind_writes='named.run' # whatever > for f in ${files_bind_writes}; do > touch ${named_chrootdir}/etc/namedb/${f} > chown bind:wheel ${named_chrootdir}/etc/namedb/${f} > done > > wouldn't work for you? I don't like the idea to write fixed list of file names; I'd like to use file system permissions to give bind right to write to directory, they (perms) exist exactly for that. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sun Aug 3 17:31:06 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70AF9106564A for ; Sun, 3 Aug 2008 17:31:06 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 068B88FC08 for ; Sun, 3 Aug 2008 17:31:05 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 26925 invoked by uid 399); 3 Aug 2008 17:31:05 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 3 Aug 2008 17:31:05 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4895EB57.2000801@FreeBSD.org> Date: Sun, 03 Aug 2008 10:31:03 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.16 (X11/20080726) MIME-Version: 1.0 To: Eugene Grosbein References: <20080803073803.GA10321@grosbein.pp.ru> In-Reply-To: <20080803073803.GA10321@grosbein.pp.ru> X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: permissions on /etc/namedb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2008 17:31:06 -0000 Eugene Grosbein wrote: > Hi! > > I need /etc/namedb to be owned by root:bind and have permissions 01775, > so bind may write to it but may not overwrite files that belong to root > here, and I made it so. I understand your frustration with something having changed that you did not expect. I would like to ask you though, what are you trying to accomplish here? What you suggested isn't really good from a security perspective because if an attacker does get in they can remove files from the directory that are owned by root and replace them with their own versions. If you give me a better idea what you're trying to do then I can give you some suggestions on how to make it happen. > I dislike it very much when a system thinks it knows better what user needs. So do I. :) In this case however I wanted to set up a system that is extremely secure by default so that the average user can be comfortable starting named in its default configuration. Obviously expert users can tweak the thing themselves. > Also, I do not want to move a place where bind writes its files to another > location just because system does not want it to write here. That's up to you of course, but it's definitely more secure in the long run to do it that way. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Sun Aug 3 18:05:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 719C4106564A for ; Sun, 3 Aug 2008 18:05:27 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id BE4438FC1B for ; Sun, 3 Aug 2008 18:05:25 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id EAA27161; Mon, 4 Aug 2008 04:04:56 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 4 Aug 2008 04:04:55 +1000 (EST) From: Ian Smith To: Mike Makonnen In-Reply-To: <4895B799.6070508@wubethiopia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Patrick Tracanelli , freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2008 18:05:27 -0000 On Sun, 3 Aug 2008, Mike Makonnen wrote: > Ian Smith wrote: > > On Fri, 1 Aug 2008, Mike Makonnen wrote: > > > Patrick Tracanelli wrote: > > > > Mike Makonnen escreveu: [..] > > /* > > * Inform divert(4) what rule to send it to by > > * modifying the port number of the associated sockaddr_in > > * structure. Note: we subtract one from the ipfw(4) rule > > * number because processing in ipfw(4) will start with > > * the next rule *after* the supplied rule number. > > */ > > if (flow->if_fwrule != 0) { > > pkt->fp_saddr.sin_port = flow->if_fwrule; > > goto enqueue; > > } > > > > and noticed that we weren't subtracting one .. > > > > The comment is wrong. It was for a prior version of the code. Initially, > I had the configuration file specify the rule number that passes the > diverted packets to dummynet(4). The code (as the comment says) would > subtract 1 from the number when it wrote the packet back, but I wasn't > sure how ipfw(4) would react to a possibly non-existant rule so changed >From my reading, that shouldn't be a problem. But I'm reading 5-STABLE sources and haven't access to my 7.0 system this week to try it out, and I could be entirely mistaken anyway! I guess it might be worth checking that the target rule number isn't less than the divert rule number that got us here, to guard against loops that $anyone might try to configure? > it to its current form. However, after thinking about it some more I > think it is more intuitive and easier to understand if the configuration > file specified the rule that passes the diverted packet to the pipe or > queue. Yes, the rule to skipto on a match, anyway. I can see doing plenty of other stuff with this than necessarily (immediately) queueing packets; depending on protocols detected you might count, log, pipe, queue with some weight, just pass, deny, test against various src/dst, whatever. > > I thought at first that this behaviour is fine, and just needed a bit > > better describing. But I'm starting to wonder if subtracting one isn't > > really a better idea? > > > > I'm leaning in the same direction. Worth a try? One thing you might test is whether it still works with net.inet.ip.fw.one_pass=1 ? That's only supposed to affect dummynet pipe diversion, but there's a bit of XXX code in after_ip_checks in ip_fw2.c (in 5-STABLE anyway) that makes me wonder about that .. > Glad to hear people are finding it useful :-) Only conceptually so far, but that's fun enough for now, while I'm really supposed to be relocating a server by sometime last week :) cheers, Ian From owner-freebsd-net@FreeBSD.ORG Sun Aug 3 18:50:40 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B853F106564A; Sun, 3 Aug 2008 18:50:40 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 182BB8FC0C; Sun, 3 Aug 2008 18:50:39 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m73IXkfD053934; Mon, 4 Aug 2008 02:33:46 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m73IXk84053932; Mon, 4 Aug 2008 02:33:46 +0800 (KRAST) (envelope-from eugen) Date: Mon, 4 Aug 2008 02:33:46 +0800 From: Eugene Grosbein To: Doug Barton Message-ID: <20080803183346.GA53252@svzserv.kemerovo.su> References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4895EB57.2000801@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@FreeBSD.org Subject: Re: permissions on /etc/namedb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2008 18:50:40 -0000 On Sun, Aug 03, 2008 at 10:31:03AM -0700, Doug Barton wrote: > >I need /etc/namedb to be owned by root:bind and have permissions 01775, > >so bind may write to it but may not overwrite files that belong to root > >here, and I made it so. > I understand your frustration with something having changed that you > did not expect. I would like to ask you though, what are you trying to > accomplish here? What you suggested isn't really good from a security > perspective because if an attacker does get in they can remove files > from the directory that are owned by root and replace them with their > own versions. Can he? Doesn't sticky bit on the directory prevent him from that? > If you give me a better idea what you're trying to do then I can give > you some suggestions on how to make it happen. Well, I just want bind be allowed to write to is working directory. Yes, it's possible to redefine it but I'd rather avoid this, to not break existing setups. > >I dislike it very much when a system thinks it knows better what user > >needs. > > So do I. :) In this case however I wanted to set up a system that is > extremely secure by default so that the average user can be > comfortable starting named in its default configuration. I agree completly. > Obviously expert users can tweak the thing themselves. So, the question is: how to tweak? > >Also, I do not want to move a place where bind writes its files to another > >location just because system does not want it to write here. > > That's up to you of course, but it's definitely more secure in the > long run to do it that way. But that way prevents named to write to its working directory, this bothers me. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sun Aug 3 19:21:48 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9B95106566B for ; Sun, 3 Aug 2008 19:21:48 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay1-bcrtfl2.verio.net (relay1-bcrtfl2.verio.net [131.103.218.142]) by mx1.freebsd.org (Postfix) with ESMTP id 66C0F8FC14 for ; Sun, 3 Aug 2008 19:21:48 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from iad-wprd-xchw01.corp.verio.net (iad-wprd-xchw01.corp.verio.net [198.87.7.164]) by relay1-bcrtfl2.verio.net (Postfix) with ESMTP id 48E4FB0380BC for ; Sun, 3 Aug 2008 15:21:47 -0400 (EDT) thread-index: Acj1niv2fJSrZ6bTSUerrCH5sY7mdw== Received: from limbo.int.dllstx01.us.it.verio.net ([10.10.10.11]) by iad-wprd-xchw01.corp.verio.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Aug 2008 15:21:46 -0400 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id 706248E29B; Sun, 3 Aug 2008 14:21:41 -0500 (CDT) Date: Sun, 3 Aug 2008 14:21:41 -0500 Content-Transfer-Encoding: 7bit From: "David DeSimone" To: Importance: normal Priority: normal Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Message-ID: <20080803192140.GJ13898@verio.net> Mail-Followup-To: freebsd-net@freebsd.org References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> MIME-Version: 1.0 Content-Type: text/plain; x-action=pgp-signed; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20080803183346.GA53252@svzserv.kemerovo.su> Precedence: bulk User-Agent: Mutt/1.5.9i X-OriginalArrivalTime: 03 Aug 2008 19:21:47.0046 (UTC) FILETIME=[2BEA1C60:01C8F59E] Subject: Re: permissions on /etc/namedb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2008 19:21:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eugene Grosbein wrote: > > I need /etc/namedb to be owned by root:bind and have permissions > 01775, so bind may write to it but may not overwrite files that belong > to root here, and I made it so. Can't you just modify /etc/mtree/BIND.chroot.dist so that it sets the permissions you desire? - -- David DeSimone == Network Admin == fox@verio.net "This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, dis- tribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you." --Lawyer Bot 6000 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFIlgVEFSrKRjX5eCoRAseOAJ9cnYx4WtYSUsUj5wDxqSitCx42hACfWIzu 0DoLbIKoc4WlseGNU6HttFE= =yQIW -----END PGP SIGNATURE----- This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From owner-freebsd-net@FreeBSD.ORG Mon Aug 4 02:56:26 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29F901065679 for ; Mon, 4 Aug 2008 02:56:26 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 600248FC14 for ; Mon, 4 Aug 2008 02:56:25 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m742uMJU002358 for ; Mon, 4 Aug 2008 10:56:22 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m742uMQ9002357 for freebsd-net@freebsd.org; Mon, 4 Aug 2008 10:56:22 +0800 (KRAST) (envelope-from eugen) Date: Mon, 4 Aug 2008 10:56:22 +0800 From: Eugene Grosbein To: freebsd-net@freebsd.org Message-ID: <20080804025622.GA2278@svzserv.kemerovo.su> References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> <20080803192140.GJ13898@verio.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080803192140.GJ13898@verio.net> User-Agent: Mutt/1.4.2.3i Subject: Re: permissions on /etc/namedb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2008 02:56:26 -0000 On Sun, Aug 03, 2008 at 02:21:41PM -0500, David DeSimone wrote: > > I need /etc/namedb to be owned by root:bind and have permissions > > 01775, so bind may write to it but may not overwrite files that belong > > to root here, and I made it so. > > Can't you just modify /etc/mtree/BIND.chroot.dist so that it sets the > permissions you desire? Yes, that might be way to go. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Aug 4 05:54:08 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C848106567F for ; Mon, 4 Aug 2008 05:54:08 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 21EFC8FC1F for ; Mon, 4 Aug 2008 05:54:08 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 17502 invoked by uid 399); 4 Aug 2008 05:54:07 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 4 Aug 2008 05:54:07 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4896997D.8060001@FreeBSD.org> Date: Sun, 03 Aug 2008 22:54:05 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.16 (X11/20080726) MIME-Version: 1.0 To: Eugene Grosbein References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> In-Reply-To: <20080803183346.GA53252@svzserv.kemerovo.su> X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: permissions on /etc/namedb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2008 05:54:08 -0000 Eugene Grosbein wrote: > On Sun, Aug 03, 2008 at 10:31:03AM -0700, Doug Barton wrote: > >>> I need /etc/namedb to be owned by root:bind and have permissions 01775, >>> so bind may write to it but may not overwrite files that belong to root >>> here, and I made it so. >> I understand your frustration with something having changed that you >> did not expect. I would like to ask you though, what are you trying to >> accomplish here? What you suggested isn't really good from a security >> perspective because if an attacker does get in they can remove files >> from the directory that are owned by root and replace them with their >> own versions. > > Can he? Doesn't sticky bit on the directory prevent him from that? That's a question that you can and should answer for yourself. (In fact one could argue that you should have answered that for yourself before you tried to set it up that way, but I digress.) :) >> If you give me a better idea what you're trying to do then I can give >> you some suggestions on how to make it happen. > > Well, I just want bind be allowed to write to is working directory. I think that your idea of "BIND's working directory" is probably flawed, but if what you want is to make /etc/namedb writable by the bind user and have it persist from boot to boot someone else already told you how to do that, so good luck. Doug PS, if you get pWn3d I don't want to hear any whinging. :) -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Mon Aug 4 06:07:02 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86479106566C; Mon, 4 Aug 2008 06:07:02 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id D81A38FC20; Mon, 4 Aug 2008 06:07:00 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m7466wSS020617; Mon, 4 Aug 2008 14:06:58 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m7466wAG020616; Mon, 4 Aug 2008 14:06:58 +0800 (KRAST) (envelope-from eugen) Date: Mon, 4 Aug 2008 14:06:58 +0800 From: Eugene Grosbein To: Doug Barton Message-ID: <20080804060658.GA19639@svzserv.kemerovo.su> References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> <4896997D.8060001@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4896997D.8060001@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@FreeBSD.org Subject: Re: permissions on /etc/namedb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2008 06:07:02 -0000 On Sun, Aug 03, 2008 at 10:54:05PM -0700, Doug Barton wrote: > >>>I need /etc/namedb to be owned by root:bind and have permissions 01775, > >>>so bind may write to it but may not overwrite files that belong to root > >>>here, and I made it so. > >>I understand your frustration with something having changed that you > >>did not expect. I would like to ask you though, what are you trying to > >>accomplish here? What you suggested isn't really good from a security > >>perspective because if an attacker does get in they can remove files > >>from the directory that are owned by root and replace them with their > >>own versions. > > > >Can he? Doesn't sticky bit on the directory prevent him from that? > > That's a question that you can and should answer for yourself. That was rhetorical quostion - I wished to give you a chance to correct yourself :-) Cheer :-) > (In fact one could argue that you should have answered that for yourself > before you tried to set it up that way, but I digress.) :) I knew right answer before tried to set up that way. > >>If you give me a better idea what you're trying to do then I can give > >>you some suggestions on how to make it happen. > > > >Well, I just want bind be allowed to write to is working directory. > > I think that your idea of "BIND's working directory" is probably > flawed That's not my idea. From /var/log/messages: Aug 3 15:02:18 host named[657]: the working directory is not writable > but if what you want is to make /etc/namedb writable by the > bind user and have it persist from boot to boot someone else already > told you how to do that, so good luck. Sigh... I have to study mtree now. And for what reason? Just because the system thinks it knows better what user needs. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Aug 4 06:39:21 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D159106566B for ; Mon, 4 Aug 2008 06:39:21 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 44B268FC12 for ; Mon, 4 Aug 2008 06:39:21 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 18372 invoked by uid 399); 4 Aug 2008 06:39:20 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 4 Aug 2008 06:39:20 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4896A416.80602@FreeBSD.org> Date: Sun, 03 Aug 2008 23:39:18 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.16 (X11/20080726) MIME-Version: 1.0 To: Eugene Grosbein References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> <4896997D.8060001@FreeBSD.org> <20080804060658.GA19639@svzserv.kemerovo.su> In-Reply-To: <20080804060658.GA19639@svzserv.kemerovo.su> X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: permissions on /etc/namedb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2008 06:39:21 -0000 Eugene Grosbein wrote: > On Sun, Aug 03, 2008 at 10:54:05PM -0700, Doug Barton wrote: > >>>>> I need /etc/namedb to be owned by root:bind and have permissions 01775, >>>>> so bind may write to it but may not overwrite files that belong to root >>>>> here, and I made it so. >>>> I understand your frustration with something having changed that you >>>> did not expect. I would like to ask you though, what are you trying to >>>> accomplish here? What you suggested isn't really good from a security >>>> perspective because if an attacker does get in they can remove files >>> >from the directory that are owned by root and replace them with their >>>> own versions. >>> Can he? Doesn't sticky bit on the directory prevent him from that? >> That's a question that you can and should answer for yourself. > > That was rhetorical quostion - I wished to give you a chance > to correct yourself :-) Cheer :-) mkdir teststicky chmod 1755 teststicky/ cd teststicky/ sudo touch foofile ls -la . total 6 drwxr-xr-t 2 dougb dougb 512 Aug 3 23:21 ./ -rw-r--r-- 1 root dougb 0 Aug 3 23:21 foofile rm foofile override rw-r--r-- root/wheel for foofile? y ls -la total 6 drwxr-xr-t 2 dougb dougb 512 Aug 3 23:22 ./ You might also want to read sticky(8), especially the bit where it says, "A file in a sticky directory may only be removed or renamed by a user if the user has write permission for the directory and the user is ... the owner of the directory ..." >>>> If you give me a better idea what you're trying to do then I can give >>>> you some suggestions on how to make it happen. >>> Well, I just want bind be allowed to write to is working directory. >> I think that your idea of "BIND's working directory" is probably >> flawed > > That's not my idea. From /var/log/messages: > > Aug 3 15:02:18 host named[657]: the working directory is not writable That is a quaint reminder of a simpler time. It's far better nowadays to separate the idea of configuration directories and directories that named should write to. (One could easily make the argument that this division should have been enforced from the start, and personally I never liked having named dropping stuff all over my config directory, but I digress.) >> but if what you want is to make /etc/namedb writable by the >> bind user and have it persist from boot to boot someone else already >> told you how to do that, so good luck. > > Sigh... I have to study mtree now. If it takes you more than 5 minutes, give up. :) > And for what reason? Just because the system thinks it knows better what user needs. You previously agreed with me that the defaults should be appropriate for non-expert users, and I would still argue that they are. Also, I'm not sure whether you've actually looked at the default named.conf or not, but the two most common files that someone would want to write are the dump and statistics files, and there are already suitable paths for those files provided, and the bind user can actually write to them by default. It would be trivial to expand those examples to other things that are of particular interest to you. Meanwhile, it's obvious to me that you are determined to go a certain direction with this, so once again I wish you luck. Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Mon Aug 4 07:55:14 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70FF2106566B; Mon, 4 Aug 2008 07:55:14 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id B9BB48FC1C; Mon, 4 Aug 2008 07:55:13 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m747tAXm030462; Mon, 4 Aug 2008 15:55:10 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m747tAVg030461; Mon, 4 Aug 2008 15:55:10 +0800 (KRAST) (envelope-from eugen) Date: Mon, 4 Aug 2008 15:55:10 +0800 From: Eugene Grosbein To: Doug Barton Message-ID: <20080804075510.GA28531@svzserv.kemerovo.su> References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> <4896997D.8060001@FreeBSD.org> <20080804060658.GA19639@svzserv.kemerovo.su> <4896A416.80602@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4896A416.80602@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: permissions on /etc/namedb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2008 07:55:14 -0000 On Sun, Aug 03, 2008 at 11:39:18PM -0700, Doug Barton wrote: > >>>>>I need /etc/namedb to be owned by root:bind and have permissions 01775, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>>>>so bind may write to it but may not overwrite files that belong to root > >>>>>here, and I made it so. > >>>>I understand your frustration with something having changed that you > >>>>did not expect. I would like to ask you though, what are you trying to > >>>>accomplish here? What you suggested isn't really good from a security > >>>>perspective because if an attacker does get in they can remove files > >>>>from the directory that are owned by root and replace them with their > >>>>own versions. > >>>Can he? Doesn't sticky bit on the directory prevent him from that? > >>That's a question that you can and should answer for yourself. > > > >That was rhetorical quostion - I wished to give you a chance > >to correct yourself :-) Cheer :-) > > mkdir teststicky > chmod 1755 teststicky/ > cd teststicky/ > sudo touch foofile > > ls -la . > total 6 > drwxr-xr-t 2 dougb dougb 512 Aug 3 23:21 ./ > -rw-r--r-- 1 root dougb 0 Aug 3 23:21 foofile > > rm foofile > override rw-r--r-- root/wheel for foofile? y > > ls -la > total 6 > drwxr-xr-t 2 dougb dougb 512 Aug 3 23:22 ./ > > You might also want to read sticky(8), especially the bit where it > says, "A file in a sticky directory may only be removed or renamed by > a user if the user has write permission for the directory and the user > is ... the owner of the directory ..." Please reread the first line of quoted text in this message. Root is the owner of /etc/namedb for my case, and bind only have right to write to its own files and create new, not touch root-owned files. > >>I think that your idea of "BIND's working directory" is probably > >>flawed > >That's not my idea. From /var/log/messages: > >Aug 3 15:02:18 host named[657]: the working directory is not writable > That is a quaint reminder of a simpler time. [skip] > Also, I'm not sure whether you've actually looked at the default > named.conf or not, but the two most common files that someone would > want to write are the dump and statistics files, and there are already > suitable paths for those files provided, and the bind user can > actually write to them by default. It would be trivial to expand those > examples to other things that are of particular interest to you. The default named.conf contains the following line: directory "/etc/namedb"; That is "the working directory" which is not writable to bind by default, hence mentioned line in /var/log/messages. I dislike when default configuration emits such warnings. So I decided to make it writable in hope this setup will save me from future problems while still secure. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Aug 4 08:48:42 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D8851065670; Mon, 4 Aug 2008 08:48:42 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id DEAC48FC1C; Mon, 4 Aug 2008 08:48:41 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m748mXTq035423; Mon, 4 Aug 2008 16:48:33 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m748mXZM035422; Mon, 4 Aug 2008 16:48:33 +0800 (KRAST) (envelope-from eugen) Date: Mon, 4 Aug 2008 16:48:33 +0800 From: Eugene Grosbein To: Remko Lodder Message-ID: <20080804084833.GA35267@svzserv.kemerovo.su> References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> <4896997D.8060001@FreeBSD.org> <20080804060658.GA19639@svzserv.kemerovo.su> <4896A416.80602@FreeBSD.org> <20080804075510.GA28531@svzserv.kemerovo.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: permissions on /etc/namedb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2008 08:48:42 -0000 On Mon, Aug 04, 2008 at 10:44:59AM +0200, Remko Lodder wrote: > I like the unwriteable /etc/namedb directory for bind, so that one is > "forced" to create directories for bind, which it has write access to. You > do not want to clobber the /etc/namedb directory with files (imo) ;) Should we change our default src/etc/namedb/named.conf in the Repository so that named won't warn about unwriteable "working directory"? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Aug 4 08:53:10 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56D8F106564A; Mon, 4 Aug 2008 08:53:10 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [IPv6:2001:418:1::39]) by mx1.freebsd.org (Postfix) with ESMTP id 37F4A8FC08; Mon, 4 Aug 2008 08:53:10 +0000 (UTC) (envelope-from randy@psg.com) Received: from [202.214.86.146] (helo=rmac.psg.com) by rip.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KPvoT-0009nE-CU; Mon, 04 Aug 2008 08:53:09 +0000 Message-ID: <4896C374.803@psg.com> Date: Mon, 04 Aug 2008 17:53:08 +0900 From: Randy Bush User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Eugene Grosbein References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> <4896997D.8060001@FreeBSD.org> <20080804060658.GA19639@svzserv.kemerovo.su> <4896A416.80602@FreeBSD.org> <20080804075510.GA28531@svzserv.kemerovo.su> <20080804084833.GA35267@svzserv.kemerovo.su> In-Reply-To: <20080804084833.GA35267@svzserv.kemerovo.su> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: permissions on /etc/namedb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2008 08:53:10 -0000 my fix to all this has been /usr/ports/dns/unbound (cache only) or /usr/ports/dns/nsd (auth only) and the developers/porters are constructive and friendly randy From owner-freebsd-net@FreeBSD.ORG Mon Aug 4 08:57:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A06011065674; Mon, 4 Aug 2008 08:57:57 +0000 (UTC) (envelope-from remko@elvandar.org) Received: from websrv01.jr-hosting.nl (websrv01.jr-hosting.nl [78.47.69.233]) by mx1.freebsd.org (Postfix) with ESMTP id 5B8308FC1C; Mon, 4 Aug 2008 08:57:57 +0000 (UTC) (envelope-from remko@elvandar.org) Received: from localhost ([::1] helo=galain.elvandar.org) by websrv01.jr-hosting.nl with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KPvt6-000N6c-AH; Mon, 04 Aug 2008 10:57:56 +0200 Received: from 145.7.91.133 (SquirrelMail authenticated user remko) by galain.elvandar.org with HTTP; Mon, 4 Aug 2008 10:57:56 +0200 (CEST) Message-ID: In-Reply-To: <20080804084833.GA35267@svzserv.kemerovo.su> References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> <4896997D.8060001@FreeBSD.org> <20080804060658.GA19639@svzserv.kemerovo.su> <4896A416.80602@FreeBSD.org> <20080804075510.GA28531@svzserv.kemerovo.su> <20080804084833.GA35267@svzserv.kemerovo.su> Date: Mon, 4 Aug 2008 10:57:56 +0200 (CEST) From: "Remko Lodder" To: "Eugene Grosbein" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: permissions on /etc/namedb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: remko@elvandar.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2008 08:57:57 -0000 On Mon, August 4, 2008 10:48 am, Eugene Grosbein wrote: > On Mon, Aug 04, 2008 at 10:44:59AM +0200, Remko Lodder wrote: > >> I like the unwriteable /etc/namedb directory for bind, so that one is >> "forced" to create directories for bind, which it has write access to. >> You >> do not want to clobber the /etc/namedb directory with files (imo) ;) > > Should we change our default src/etc/namedb/named.conf in the Repository > so that named won't warn about unwriteable "working directory"? > > Eugene Grosbein > Hi, I dont think so.. I think the current default is fine, if you want to write files to it, then you need to change things, best is to use seperated directories. Note that you need to change things anyway because the server listens on localhost by default. So, if you want things differently; you have to customize it. Sounds like a fair deal to me ;) (the defaults that is) -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-net@FreeBSD.ORG Mon Aug 4 09:00:03 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D97B91065676 for ; Mon, 4 Aug 2008 09:00:03 +0000 (UTC) (envelope-from remko@elvandar.org) Received: from websrv01.jr-hosting.nl (websrv01.jr-hosting.nl [78.47.69.233]) by mx1.freebsd.org (Postfix) with ESMTP id 8D9E18FC15 for ; Mon, 4 Aug 2008 09:00:03 +0000 (UTC) (envelope-from remko@elvandar.org) Received: from localhost ([::1] helo=galain.elvandar.org) by websrv01.jr-hosting.nl with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KPvgZ-000MxR-HU; Mon, 04 Aug 2008 10:44:59 +0200 Received: from 145.7.91.133 (SquirrelMail authenticated user remko) by galain.elvandar.org with HTTP; Mon, 4 Aug 2008 10:44:59 +0200 (CEST) Message-ID: In-Reply-To: <20080804075510.GA28531@svzserv.kemerovo.su> References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> <4896997D.8060001@FreeBSD.org> <20080804060658.GA19639@svzserv.kemerovo.su> <4896A416.80602@FreeBSD.org> <20080804075510.GA28531@svzserv.kemerovo.su> Date: Mon, 4 Aug 2008 10:44:59 +0200 (CEST) From: "Remko Lodder" To: "Eugene Grosbein" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: permissions on /etc/namedb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: remko@elvandar.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2008 09:00:04 -0000 On Mon, August 4, 2008 9:55 am, Eugene Grosbein wrote: > On Sun, Aug 03, 2008 at 11:39:18PM -0700, Doug Barton wrote: > >> >>>>>I need /etc/namedb to be owned by root:bind and have permissions >> 01775, > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >>>>>so bind may write to it but may not overwrite files that belong to >> root >> >>>>>here, and I made it so. >> >>>>I understand your frustration with something having changed that you >> >>>>did not expect. I would like to ask you though, what are you trying >> to >> >>>>accomplish here? What you suggested isn't really good from a >> security >> >>>>perspective because if an attacker does get in they can remove files >> >>>>from the directory that are owned by root and replace them with >> their >> >>>>own versions. >> >>>Can he? Doesn't sticky bit on the directory prevent him from that? >> >>That's a question that you can and should answer for yourself. >> > >> >That was rhetorical quostion - I wished to give you a chance >> >to correct yourself :-) Cheer :-) >> >> mkdir teststicky >> chmod 1755 teststicky/ >> cd teststicky/ >> sudo touch foofile >> >> ls -la . >> total 6 >> drwxr-xr-t 2 dougb dougb 512 Aug 3 23:21 ./ >> -rw-r--r-- 1 root dougb 0 Aug 3 23:21 foofile >> >> rm foofile >> override rw-r--r-- root/wheel for foofile? y >> >> ls -la >> total 6 >> drwxr-xr-t 2 dougb dougb 512 Aug 3 23:22 ./ >> >> You might also want to read sticky(8), especially the bit where it >> says, "A file in a sticky directory may only be removed or renamed by >> a user if the user has write permission for the directory and the user >> is ... the owner of the directory ..." > > Please reread the first line of quoted text in this message. > Root is the owner of /etc/namedb for my case, and bind only have right > to write to its own files and create new, not touch root-owned files. > >> >>I think that your idea of "BIND's working directory" is probably >> >>flawed >> >That's not my idea. From /var/log/messages: >> >Aug 3 15:02:18 host named[657]: the working directory is not writable >> That is a quaint reminder of a simpler time. > > [skip] > >> Also, I'm not sure whether you've actually looked at the default >> named.conf or not, but the two most common files that someone would >> want to write are the dump and statistics files, and there are already >> suitable paths for those files provided, and the bind user can >> actually write to them by default. It would be trivial to expand those >> examples to other things that are of particular interest to you. > > The default named.conf contains the following line: > > directory "/etc/namedb"; > > That is "the working directory" which is not writable to bind by default, > hence mentioned line in /var/log/messages. I dislike when default > configuration emits such warnings. So I decided to make it writable > in hope this setup will save me from future problems while still secure. > > Eugene Grosbein > _______________________________________________ Hello, I like the unwriteable /etc/namedb directory for bind, so that one is "forced" to create directories for bind, which it has write access to. You do not want to clobber the /etc/namedb directory with files (imo) ;) Cheers remko -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-net@FreeBSD.ORG Mon Aug 4 09:09:53 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B1701065676; Mon, 4 Aug 2008 09:09:53 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 5D20C8FC08; Mon, 4 Aug 2008 09:09:51 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m7499i5N037308; Mon, 4 Aug 2008 17:09:44 +0800 (KRAST) (envelope-from eugen@kuzbass.ru) Message-ID: <4896C759.D7FD6E8B@kuzbass.ru> Date: Mon, 04 Aug 2008 17:09:45 +0800 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: remko@elvandar.org References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> <4896997D.8060001@FreeBSD.org> <20080804060658.GA19639@svzserv.kemerovo.su> <4896A416.80602@FreeBSD.org> <20080804075510.GA28531@svzserv.kemerovo.su> <20080804084833.GA35267@svzserv.kemerovo.su> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: permissions on /etc/namedb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2008 09:09:53 -0000 Remko Lodder wrote: > > Should we change our default src/etc/namedb/named.conf in the Repository > > so that named won't warn about unwriteable "working directory"? > > I dont think so.. I think the current default is fine, if you want to > write files to it, then you need to change things, best is to use > seperated directories. Note that you need to change things anyway because > the server listens on localhost by default. So, if you want things > differently; you have to customize it. Sounds like a fair deal to me ;) > (the defaults that is) Perhaps, then there should be a note in a comment for "directory" line about all this stuff and named's warning in the log? This warning may be quite confusing. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Aug 4 10:57:24 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D94811065676; Mon, 4 Aug 2008 10:57:24 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id D45618FC16; Mon, 4 Aug 2008 10:57:22 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id UAA23877; Mon, 4 Aug 2008 20:57:19 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 4 Aug 2008 20:57:18 +1000 (EST) From: Ian Smith To: Doug Barton In-Reply-To: <4896A416.80602@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, Eugene Grosbein Subject: Re: permissions on /etc/namedb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2008 10:57:24 -0000 On Sun, 3 Aug 2008, Doug Barton wrote: > Eugene Grosbein wrote: > > On Sun, Aug 03, 2008 at 10:54:05PM -0700, Doug Barton wrote: [..] > >>> Well, I just want bind be allowed to write to is working directory. > >> I think that your idea of "BIND's working directory" is probably > >> flawed > > > > That's not my idea. From /var/log/messages: > > > > Aug 3 15:02:18 host named[657]: the working directory is not writable > > That is a quaint reminder of a simpler time. It's far better nowadays > to separate the idea of configuration directories and directories that > named should write to. (One could easily make the argument that this > division should have been enforced from the start, and personally I > never liked having named dropping stuff all over my config directory, > but I digress.) In the olden days (bind 4) named.run, named.stats and named_dump.db were all written to /var/tmp .. perhaps because it had the sticky bit set? > >> but if what you want is to make /etc/namedb writable by the > >> bind user and have it persist from boot to boot someone else already > >> told you how to do that, so good luck. > > > > Sigh... I have to study mtree now. > > If it takes you more than 5 minutes, give up. :) > > > And for what reason? Just because the system thinks it knows better what user needs. > > You previously agreed with me that the defaults should be appropriate > for non-expert users, and I would still argue that they are. With the notable exception of making standard functions rndc trace and querylog work, writing to the default file named.run, which named wants to write in 'the working directory'. You'll have seen my solution to that, touching named.run in case it doesn't exist then chown'ing it to bind:wheel in /etc/rc.d/named, which I don't think endangers security. I've not been able to find another solution, and there's no equivalent of dump-file and statistics-file for the trace/querylog file (that I can find) but perhaps you know some way the directory to write this file can be specified in named.conf? Maybe to /var/named/var/log ? > Also, I'm not sure whether you've actually looked at the default > named.conf or not, but the two most common files that someone would > want to write are the dump and statistics files, and there are already > suitable paths for those files provided, and the bind user can > actually write to them by default. It would be trivial to expand those > examples to other things that are of particular interest to you. That's what I thought, but my extensive reading hasn't shown me how to do that for named.run, so I'd appreciate a clue for a better solution. cheers, Ian From owner-freebsd-net@FreeBSD.ORG Mon Aug 4 11:06:59 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 770B51065677 for ; Mon, 4 Aug 2008 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5DA578FC25 for ; Mon, 4 Aug 2008 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m74B6xVl082141 for ; Mon, 4 Aug 2008 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m74B6wSC082137 for freebsd-net@FreeBSD.org; Mon, 4 Aug 2008 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Aug 2008 11:06:58 GMT Message-Id: <200808041106.m74B6wSC082137@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2008 11:06:59 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net [patch] changing interface ipaddress doesn't seem to w s kern/39937 net ipstealth issue s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau f kern/102344 net [ipf] Some packets do not pass through network interfa o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109733 net [bge] bge link state issues [regression] o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122685 net It is not visible passing packets in tcpdump o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar f conf/122858 net [nsswitch.conf] nsswitch in 7.0 is f*cked up o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123172 net [bce] Watchdog timeout problems with if_bce f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123617 net [tcp] breaking connection when client downloading file o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o bin/125922 net [patch] Deadlock in arp(8) o kern/126075 net [in] Network: internet control accesses beyond end of o kern/126214 net [ath] txpower problem with Atheros wifi card 98 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) [regression] o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122928 net [em] interface watchdog timeouts and stops receiving p o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) o kern/123892 net [tap] [patch] No buffer space available p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/125181 net [ndis] [patch] with wep enters kdb.enter.unknown, pani o kern/125239 net [gre] kernel crash when using gre o kern/125258 net [socket] socket's SO_REUSEADDR option does not work f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125816 net [carp] [bridge] carp stuck in init when using bridge i o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard 59 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Aug 4 13:36:29 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E2A51065676 for ; Mon, 4 Aug 2008 13:36:29 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (capeta.freebsdbrasil.com.br [201.48.151.3]) by mx1.freebsd.org (Postfix) with SMTP id 990B88FC0C for ; Mon, 4 Aug 2008 13:36:28 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 59249 invoked from network); 4 Aug 2008 10:36:26 -0300 Received: by simscan 1.1.0 ppid: 59233, pid: 59234, t: 8.2815s scanners: clamav: 0.91.1/m: spam: 3.1.1 X-Spam-Checker-Version: SpamAssassin: -last, FreeBSD Brasil LTDA rulesets: Yes X-Spam-Status: No, hits=-2.0 required=3.7 Received: from unknown (HELO claire.bh.freebsdbrasil.com.br) (201.48.151.226) by capeta.freebsdbrasil.com.br with SMTP; 4 Aug 2008 10:36:17 -0300 Message-ID: <48970597.3030407@freebsdbrasil.com.br> Date: Mon, 04 Aug 2008 10:35:19 -0300 From: Patrick Tracanelli Organization: FreeBSD Brasil LTDA User-Agent: Thunderbird 2.0.0.0 (X11/20070612) MIME-Version: 1.0 To: Mike Makonnen References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> <48922E9D.1020507@elischer.org> <4893328C.2040105@freebsdbrasil.com.br> <4894447C.3000800@wubethiopia.com> <48945A79.50300@wubethiopia.com> In-Reply-To: <48945A79.50300@wubethiopia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2008 13:36:29 -0000 Mike Makonnen escreveu: > Mike Makonnen wrote: >> Patrick Tracanelli wrote: >>> >>> To let you know of my current (real world) tests: >>> >>> - Wireless Internet Provider 1: >>> - 4Mbit/s of Internet Traffic >>> - Classifying default protocols + soulseek + ssh >>> - Classifying 100Mbit/s of dump over ssh >>> >>> Results in: >>> No latency added, very low CPU usage, no packets dropping. >>> >>> - Wireless ISP 2: >>> - 21 Mbit/s of Internet Traffic >>> - Classifying default protocols + soulseek + ssh >>> >>> Results in: >>> No tcp or udp traffic at all; everything that gets diverted never >>> comes out of the divert socket, and ipfw-classifyd logs >>> >>> Aug 1 12:07:35 ourofino last message repeated 58 times >>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: bittorrent >>> (rule 50000) >>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: edonkey >>> (rule 50000) >>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: fasttrack >>> (rule 50000) >>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: gnutella >>> (rule 1000) >>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: soulseek >>> (rule 50000) >>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: ssh (rule >>> 50000) >>> Aug 1 12:18:28 ourofino ipfw-classifyd: unable to write to divert >>> socket: Operation not permitted >>> Aug 1 12:18:50 ourofino last message repeated 90 times >> >> Hmmm... this part means that the call to sendto(2) to write the packet >> back into network stack failed. This explains why you are not seein g >> any traffic comming back out of the divert socket, but I don't see why >> it would suddenly fail with a permission error. Could this be a kernel >> bug? >>> Aug 1 12:18:51 ourofino ipfw-classifyd: packet dropped: input queue >>> full >>> Aug 1 12:19:11 ourofino last message repeated 94 times >>> >>> Raised queue len a lot (up to 40960), when the application starts it >>> uses up to 25% CPU and a second after that, CPU usage gets lower the >>> 0.1%. >> >> This looks like a deadlock. If it weren't able to process packets fast >> enough the cpu usage should be high even as it's spewing "packet >> dropped" messages. Can you send me some more information like memory >> usage and the firewall script you are using? How much of the 21Mbits/s >> of traffic is P2P? If you reduce the number of protocols you are >> trying to match against does the behavior change? Using netstat -w1 >> -I can you tell me how many packets per second we're >> talking about for 4Mbits/s and 21Mbit/s? Also, the timestamps from the >> log file seem to show that the daemon is running for approx. 34 sec. >> before the first "unable to write to write to divert socket" message. >> Is it passing traffic during this time? Thanks. >> >> I've uploaded a newer version. Can you try that also please. It includes: >> o SIGHUP forces it to re-read its configuration file >> o rc.d script >> o minor optimization (calls pthread_cond_signal with the mutex >> unlocked) >> o code cleanup >> >> Also, for your convenience I have attached a patch against the earlier >> version that removes a debugging printf that should remove spammage to >> your log files (the current version has it removed already). >> > > Ooops, a few minutes after I sent this email I found a couple of bugs > (one major, and one minor). They were in the original tarball as well as > the newer one I uploaded earlier today. I've uploaded a fixed version of > the code. Can you try that instead please. > > Also, to help track down performance issues I've modified the Makefile > to build a profiled version of the application so you can use gprof(1) > to figure out where any problems lie. > > Cheers. > On gcc 3.4.6, -Wno-pointer-sign compiler switch is unknown and therefore compiling fails: cc -O2 -fno-strict-aliasing -pipe -O2 -pipe -pg -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c classifyd.c cc1: error: unrecognized command line option "-Wno-pointer-sign" *** Error code 1 Stop in /usr/home/setup/ipfw-classifyd. If removed, does compile fine. On amd64 does not compile: cc -O2 -fno-strict-aliasing -pipe -O2 -pipe -pg -g -Wsystem-headers -Werror -Wall -Wno- format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer -arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunus ed-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer -sign -fPIC -pipe -c classifyd.c cc1: warnings being treated as errors classifyd.c: In function 'write_pthread': classifyd.c:813: warning: format '%d' expects type 'int', but argument 4 has type 'size_ t' *** Error code 1 The rules Im running: 00001 1379 320702 fwd 192.168.100.11 ip from any to { 201.91.17.200/29 or dst-ip 189.44.216.168/29 } out via fxp0 00002 0 0 fwd 192.168.100.11 ip from any to { 201.91.17.200/29 or dst-ip 189.44.216.168/29 } out via fxp2 00003 39137 7760042 fwd 189.52.140.1 ip from 189.52.140.10 to any out via fxp0 00004 34462 10801535 fwd 189.52.140.3 ip from 189.52.140.11 to any out via fxp0 00005 68780 29374414 fwd 189.52.140.1 ip from 189.52.140.18 to any out via fxp0 00006 12154 2003678 fwd 189.52.140.3 ip from 189.52.140.19 to any out via fxp0 00500 4741 770166 divert 7777 tcp from any to any via fxp0 00501 172 38599 divert 7777 udp from any to any via fxp0 49999 823215 453482966 allow ip from any to any 65535 0 0 allow ip from any to any Memory usage while running classifyd: Mem: 67M Active, 27M Inact, 44M Wired, 24K Cache, 111M Buf, 859M Free Swap: 1024M Total, 1024M Free classifyd's CPU usage: 5198 root 3 20 0 6132K 5420K kserel 1:14 24.52% ipfw-classifyd System load averga for 5 minutes is 0.2 while not running classifyd and 0.8 while running. Logs with the latest (downloaded a few minutes ago) code: Aug 4 10:15:29 ourofino ipfw-classifyd: Loaded Protocol: bittorrent (rule 50000) Aug 4 10:15:29 ourofino ipfw-classifyd: Loaded Protocol: edonkey (rule 50000) Aug 4 10:15:29 ourofino ipfw-classifyd: Loaded Protocol: fasttrack (rule 50000) Aug 4 10:15:29 ourofino ipfw-classifyd: Loaded Protocol: gnutella (rule 50000) Aug 4 10:15:29 ourofino ipfw-classifyd: Loaded Protocol: soulseek (rule 50000) Aug 4 10:15:29 ourofino ipfw-classifyd: Loaded Protocol: ssh (rule 50000) Aug 4 10:15:36 ourofino ipfw-classifyd: packet dropped: input queue full Aug 4 10:16:07 ourofino last message repeated 1594 times Aug 4 10:16:19 ourofino last message repeated 766 times I miss the debug lines! ;D # netstat -w1 -I fxp0 input (fxp0) output packets errs bytes packets errs bytes colls 535 0 286009 515 0 165965 0 416 0 347448 456 0 153585 0 444 0 309008 449 0 185087 0 493 0 190090 474 0 202637 0 547 0 197882 562 0 233751 0 409 0 288318 461 0 249421 0 434 0 173193 464 0 261512 0 437 0 246516 450 0 258908 0 458 0 200348 481 0 157800 0 423 0 250006 427 0 97723 0 367 0 261323 349 0 96405 0 592 0 178843 556 0 91032 0 450 0 248174 432 0 112650 0 390 0 244258 349 0 106532 0 442 0 303159 392 0 125664 0 407 0 237804 350 0 84367 0 460 0 207586 456 0 86633 0 364 0 200758 366 0 99798 0 313 0 241031 325 0 85746 0 463 0 248284 470 0 113385 0 With above protocols, wont matter if I run with the default queue len, with -q 4096 or -q 40960. Its always never enough and I get the "input queue full" logs. However, if I remove add only 1 or 2 protocols (tried bittorrend only and later, edonkey only), things do work fine, for a few seconds, but than: Aug 4 10:22:58 ourofino ipfw-classifyd: Loaded Protocol: bittorrent (rule 50000) Aug 4 10:24:32 ourofino ipfw-classifyd: Loaded Protocol: bittorrent (rule 50000) Aug 4 10:28:02 ourofino ipfw-classifyd: unable to write to divert socket: Invalid argument Aug 4 10:28:33 ourofino last message repeated 20 times Aug 4 10:29:03 ourofino last message repeated 18 times Aug 4 10:29:05 ourofino kernel: pid 5654 (ipfw-classifyd), uid 0: exited on signal 6 (core dumped) Aug 4 10:30:06 ourofino ipfw-classifyd: Loaded Protocol: bittorrent (rule 50000) Aug 4 10:30:08 ourofino ipfw-classifyd: packet dropped: input queue full Aug 4 10:30:09 ourofino last message repeated 186 times Aug 4 10:30:17 ourofino ipfw-classifyd: unable to write to divert socket: Invalid argument Aug 4 10:30:27 ourofino last message repeated 2 times Aug 4 10:32:43 ourofino ipfw-classifyd: Loaded Protocol: edonkey (rule 50000) Aug 4 10:33:04 ourofino ipfw-classifyd: unable to write to divert socket: Invalid argument Aug 4 10:33:22 ourofino last message repeated 11 times Aug 4 10:33:23 ourofino kernel: pid 5901 (ipfw-classifyd), uid 0: exited on signal 6 (core dumped) I get the " unable to write to divert socket: Invalid argument" constantly and when classifyd dies (core dump with signal 6) I get the following debug output: Assertion failed: (datalen >= 0), function classify_pthread, file classifyd.c, line 646. What other useful output I can send you? -- Patrick Tracanelli From owner-freebsd-net@FreeBSD.ORG Mon Aug 4 13:56:50 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B80F1065792 for ; Mon, 4 Aug 2008 13:56:50 +0000 (UTC) (envelope-from ady@ady.ro) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by mx1.freebsd.org (Postfix) with ESMTP id 0C8DF8FC18 for ; Mon, 4 Aug 2008 13:56:44 +0000 (UTC) (envelope-from ady@ady.ro) Received: by wf-out-1314.google.com with SMTP id 24so1792253wfg.7 for ; Mon, 04 Aug 2008 06:56:44 -0700 (PDT) Received: by 10.142.203.19 with SMTP id a19mr4936696wfg.179.1217856601086; Mon, 04 Aug 2008 06:30:01 -0700 (PDT) Received: by 10.142.54.14 with HTTP; Mon, 4 Aug 2008 06:30:01 -0700 (PDT) Message-ID: <78cb3d3f0808040630o7ad311a5r6da8f821d2bfe63a@mail.gmail.com> Date: Mon, 4 Aug 2008 15:30:01 +0200 From: "Adrian Penisoara" Sender: ady@ady.ro To: "Ian Smith" In-Reply-To: MIME-Version: 1.0 References: <4896A416.80602@FreeBSD.org> X-Google-Sender-Auth: c965ee155b768b1d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Doug Barton , Eugene Grosbein Subject: Re: permissions on /etc/namedb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2008 13:56:50 -0000 Hi, On Mon, Aug 4, 2008 at 12:57 PM, Ian Smith wrote: > On Sun, 3 Aug 2008, Doug Barton wrote: > > Eugene Grosbein wrote: > > > On Sun, Aug 03, 2008 at 10:54:05PM -0700, Doug Barton wrote: > [..] > > >>> Well, I just want bind be allowed to write to is working directory. > > >> I think that your idea of "BIND's working directory" is probably > > >> flawed > > > > > > That's not my idea. From /var/log/messages: > > > > > > Aug 3 15:02:18 host named[657]: the working directory is not writable > > > > That is a quaint reminder of a simpler time. It's far better nowadays > > to separate the idea of configuration directories and directories that > > named should write to. (One could easily make the argument that this > > division should have been enforced from the start, and personally I > > never liked having named dropping stuff all over my config directory, > > but I digress.) > > In the olden days (bind 4) named.run, named.stats and named_dump.db were > all written to /var/tmp .. perhaps because it had the sticky bit set? > > > >> but if what you want is to make /etc/namedb writable by the > > >> bind user and have it persist from boot to boot someone else already > > >> told you how to do that, so good luck. > > > > > > Sigh... I have to study mtree now. > > > > If it takes you more than 5 minutes, give up. :) > > > > > And for what reason? Just because the system thinks it knows better > what user needs. > > > > You previously agreed with me that the defaults should be appropriate > > for non-expert users, and I would still argue that they are. > > With the notable exception of making standard functions rndc trace and > querylog work, writing to the default file named.run, which named wants > to write in 'the working directory'. You'll have seen my solution to > that, touching named.run in case it doesn't exist then chown'ing it to > bind:wheel in /etc/rc.d/named, which I don't think endangers security. > > I've not been able to find another solution, and there's no equivalent > of dump-file and statistics-file for the trace/querylog file (that I Quoting from a default distributed /etc/namedb/named.conf: options { // Relative to the chroot directory, if any directory "/etc/namedb"; pid-file "/var/run/named/pid"; dump-file "/var/dump/named_dump.db"; statistics-file "/var/stats/named.stats"; You have to take into account that "directory" is used for any non-absolute pathname specified in named.conf, including the "file" clauses for master/slave zones. If you were to change it now then you would break a lot of setups. I believe that the "working directory" and "root config directory" concepts should have been dissociated. > > can find) but perhaps you know some way the directory to write this > file can be specified in named.conf? Maybe to /var/named/var/log ? > > > Also, I'm not sure whether you've actually looked at the default > > named.conf or not, but the two most common files that someone would > > want to write are the dump and statistics files, and there are already > > suitable paths for those files provided, and the bind user can > > actually write to them by default. It would be trivial to expand those > > examples to other things that are of particular interest to you. > > That's what I thought, but my extensive reading hasn't shown me how to > do that for named.run, so I'd appreciate a clue for a better solution. > Best is to have a sepatate configuration directive for the "working directory" versus "root config directory" assumed by the current "directory" statement. Another idea would be to add a final "options { directory "/var/run/named"; }; " statement at the end of the file -- from the BIND sources it appears that there is a callback function which may pickup this final statement in order to make it the current working directory for the named process. Oh, and in the idea that we should keep the default configuration as simple as possible for the average user and for whatever scenario, here is my proposal: directory "/etc/namedb"; pid-file "/var/run/named/pid"; dump-file "/var/run/named/named_dump.db"; statistics-file "/var/run/named/named.stats"; Now the reasons: - the directory statement should remain the same in order not to break existing "file" functionality for DNS zones; - we should use /var/run/named since this is the single common path available for both chrooted and non-chrooted setups; - rather then dispersing the various output files we should standardize for a single common output location I'm not sure what happens when the user toggles tracing / query logging (with rndc) -- where would these files go by default ? My 2cents, Adrian. From owner-freebsd-net@FreeBSD.ORG Mon Aug 4 18:46:22 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DAA51065674 for ; Mon, 4 Aug 2008 18:46:22 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 0A1AA8FC15 for ; Mon, 4 Aug 2008 18:46:21 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 30181 invoked by uid 399); 4 Aug 2008 18:46:21 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 4 Aug 2008 18:46:21 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <48974E7B.5050401@FreeBSD.org> Date: Mon, 04 Aug 2008 11:46:19 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.16 (X11/20080726) MIME-Version: 1.0 To: Randy Bush References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> <4896997D.8060001@FreeBSD.org> <20080804060658.GA19639@svzserv.kemerovo.su> <4896A416.80602@FreeBSD.org> <20080804075510.GA28531@svzserv.kemerovo.su> <20080804084833.GA35267@svzserv.kemerovo.su> <4896C374.803@psg.com> In-Reply-To: <4896C374.803@psg.com> X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Eugene Grosbein Subject: Re: permissions on /etc/namedb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2008 18:46:22 -0000 Randy Bush wrote: > my fix to all this has been > /usr/ports/dns/unbound (cache only) > or > /usr/ports/dns/nsd (auth only) > > and the developers/porters are constructive and friendly Oddly enough I think of myself as constructive and friendly. :) However I can't make a default configuration that fits everyone's needs. I can only do what I can to make it safe by default. Of course the two alternatives you listed are good ones, and I encourage my clients to investigate them for their environments even if they continue using BIND since IMO diversity is a good thing, helps improve resilience, etc. Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Mon Aug 4 18:50:16 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 594C71065670 for ; Mon, 4 Aug 2008 18:50:16 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id AF8768FC0C for ; Mon, 4 Aug 2008 18:50:15 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 4383 invoked by uid 399); 4 Aug 2008 18:50:15 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 4 Aug 2008 18:50:15 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <48974F65.7050301@FreeBSD.org> Date: Mon, 04 Aug 2008 11:50:13 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.16 (X11/20080726) MIME-Version: 1.0 To: Eugene Grosbein References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> <4896997D.8060001@FreeBSD.org> <20080804060658.GA19639@svzserv.kemerovo.su> <4896A416.80602@FreeBSD.org> <20080804075510.GA28531@svzserv.kemerovo.su> In-Reply-To: <20080804075510.GA28531@svzserv.kemerovo.su> X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: permissions on /etc/namedb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2008 18:50:16 -0000 Eugene Grosbein wrote: > On Sun, Aug 03, 2008 at 11:39:18PM -0700, Doug Barton wrote: > >>>>>>> I need /etc/namedb to be owned by root:bind and have permissions 01775, Fair enough, I misread that bit. Sorry for the confusion. I will (once again) return to my point that while I do not think what you are proposing is an appropriate default, you have the tools to do what you want to do, so good luck with it. -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Mon Aug 4 21:46:26 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42AA7106566B for ; Mon, 4 Aug 2008 21:46:26 +0000 (UTC) (envelope-from apache@www.377963.com) Received: from www.377963.com (377963.com [211.125.77.37]) by mx1.freebsd.org (Postfix) with ESMTP id C5E798FC1B for ; Mon, 4 Aug 2008 21:46:25 +0000 (UTC) (envelope-from apache@www.377963.com) Received: (from apache@localhost) by www.377963.com (8.11.6/8.11.6) id m74L9BR15139; Tue, 5 Aug 2008 06:09:11 +0900 Date: Tue, 5 Aug 2008 06:09:11 +0900 Message-Id: <200808042109.m74L9BR15139@www.377963.com> To: freebsd-net@freebsd.org From: DarkStone MuOnline Server Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: DarkStone MuOnline Server Challenge you To a Duel. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mu@online.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2008 21:46:26 -0000 [votenew.jpg] _________________________________________________________________ [pixel.gif] www.darkstonemu.net [pixel.gif] [pixel.gif] [pixel.gif] [pixel.gif] [muonlinedarkstoneadv256vo4.gif] DarkStone MuOnline DarkStone MU Online is a MMORPG that takes the player, into a fantasy world full of excitement, adventure and monsters. With several ways to train a character, multiple character classes, and a vast continent to explore, GMO is a sure way to a unique adventure. Join thousands of players from all over the world and help defend the Continent of Legend, clearing it from the clenches of Kundun and his forces forever. . With new content and features being introduced regularly, this game is perfect for those looking for an exciting MMO experience. [pixel.gif] [pixel.gif] [pixel.gif] You start off as a Dark Wizard, a Dark Knight, Dark Lord, Magic GLadiator, a Summoner or a Fairy Elf, with accordant strengths and weaknesses. You can save different base characters, a fun feature that allows you to begin play as a wizard, and later, restart and switch to a knight--but not both at the same time. The look of your character changes to reflect any new accoutrements you get, including wings and spells. There's also a coordinate system on display, so it's easier to move around the elaborate MU world. Items can be combined in many different ways, but more game experience gets you better gear. You can even fight other players, but be warned: if you kill too many innocents, you'll be branded a murderer. Server Stats: ON * Experience: 1000x * Drops: 80% * Reset Level: 399 keep stats * Shops: +7 items. (you have to find some shops for the good items.) * Bless Bug On * Register: http://www.darkstonemu.net/DarkStone-Register.html * Download: http://www.darkstonemu.net/DarkStone-Downloads.html Official Game Installer: http://darkstonemu.net/Download/DarkStoneMu.exe In order to play free just enter your [1]Site and download the [2]Client. We encourage you to visit the DarkStone MU Online forums at [3]http://darkstonemu.net/ _________________________________________________________________ *Please do not respond to this e-mail as your reply will not be received. References 1. http://www.darkstonemu.net/DarkStone-Register.html 2. http://www.darkstonemu.net/DarkStone-Downloads.html 3. http://www.craiova-online.ro/rds-mu-server-212/ From owner-freebsd-net@FreeBSD.ORG Mon Aug 4 22:40:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03C781065676 for ; Mon, 4 Aug 2008 22:40:57 +0000 (UTC) (envelope-from dcornejo@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 7F79D8FC23 for ; Mon, 4 Aug 2008 22:40:56 +0000 (UTC) (envelope-from dcornejo@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so2995510fgb.35 for ; Mon, 04 Aug 2008 15:40:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=X5bXtYK8g4QiUiSbUcl3+cSk3loPUY0r/QL2x2mdbrY=; b=QcV/o9nAgycwvRG8hscM9TDxZZTz82ETT0TFyg4TqmT4EmHDNBxNTYLLMecMqmT0XG SBr0CglUCq134jw8rwTY7PyNZs9BW0SWwCQpac3FNal4McYOLGWeWOfuQF29E7lFF3/I 0OFlw+ZpxCyZYSOjYYZpOKlejSnZpnEowsaSE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=F+bzF4+vFErM1Nzq/dyauwGpJCo66EHjaeOnD8cZIKPjZOa+fm4ygCVWijR4nzalFV dWHvgsult+r7dQpW6hMiwCSL9ltZqCNTmftqqxpQuSi0wLqIOBi/sd6R2n+tRPcdFF7u 1FuLRGwdyHQnqj60aj9sqWBcJ9MBPr54oq6HU= Received: by 10.125.80.14 with SMTP id h14mr13115mkl.41.1217887989331; Mon, 04 Aug 2008 15:13:09 -0700 (PDT) Received: by 10.125.15.1 with HTTP; Mon, 4 Aug 2008 15:13:09 -0700 (PDT) Message-ID: <6b8e8f4f0808041513x2537c723vd575f0760cf53e02@mail.gmail.com> Date: Mon, 4 Aug 2008 12:13:09 -1000 From: "David Cornejo" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: bridging wireless station X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2008 22:40:57 -0000 hi, i would like to bridge a wireless client to ethernet (in 8-CURRENT) - the last bug in the if_bridge man page says this is a no-no. the question is whether this could be worked around - don't need the highest performance, so maybe netgraph or even a userland daemon would work. i don't have any ability to do anything at the access point end so some of the tunneling protocols are out any thoughts are appreciated, thanks, From owner-freebsd-net@FreeBSD.ORG Mon Aug 4 22:48:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED9D51065676 for ; Mon, 4 Aug 2008 22:48:07 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id C76068FC27 for ; Mon, 4 Aug 2008 22:48:07 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m74Mm6rr045196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Aug 2008 15:48:07 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <48978726.3060501@freebsd.org> Date: Mon, 04 Aug 2008 15:48:06 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: David Cornejo References: <6b8e8f4f0808041513x2537c723vd575f0760cf53e02@mail.gmail.com> In-Reply-To: <6b8e8f4f0808041513x2537c723vd575f0760cf53e02@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: freebsd-net@freebsd.org Subject: Re: bridging wireless station X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2008 22:48:08 -0000 David Cornejo wrote: > hi, > > i would like to bridge a wireless client to ethernet (in 8-CURRENT) - > the last bug in the if_bridge man page says this is a no-no. > > the question is whether this could be worked around - don't need the > highest performance, so maybe netgraph or even a userland daemon would > work. i don't have any ability to do anything at the access point end > so some of the tunneling protocols are out > > any thoughts are appreciated, > > The man page is out of date; HEAD has WDS support now so you can bridge traffic that's 4-address encapsulated. You might try to be more clear what you're trying to setup. Sam From owner-freebsd-net@FreeBSD.ORG Mon Aug 4 22:58:47 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AE11106567A for ; Mon, 4 Aug 2008 22:58:47 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 197B58FC1B for ; Mon, 4 Aug 2008 22:58:47 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 678322BC5B; Tue, 5 Aug 2008 10:58:45 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoqGC8hL8sP3; Tue, 5 Aug 2008 10:58:41 +1200 (NZST) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Tue, 5 Aug 2008 10:58:41 +1200 (NZST) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id A1A621142F; Tue, 5 Aug 2008 10:58:40 +1200 (NZST) Date: Mon, 4 Aug 2008 15:58:40 -0700 From: Andrew Thompson To: David Cornejo Message-ID: <20080804225840.GC6737@citylink.fud.org.nz> References: <6b8e8f4f0808041513x2537c723vd575f0760cf53e02@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6b8e8f4f0808041513x2537c723vd575f0760cf53e02@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-net@freebsd.org Subject: Re: bridging wireless station X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2008 22:58:47 -0000 On Mon, Aug 04, 2008 at 12:13:09PM -1000, David Cornejo wrote: > hi, > > i would like to bridge a wireless client to ethernet (in 8-CURRENT) - > the last bug in the if_bridge man page says this is a no-no. The bridge man page needs to be updated as its possible to do this now. > the question is whether this could be worked around - don't need the > highest performance, so maybe netgraph or even a userland daemon would > work. i don't have any ability to do anything at the access point end > so some of the tunneling protocols are out The system supports wdslegacy and dwds modes. lecacy takes a static bssid address to forward the traffic to, this mode can only be encrypted with wep. dwds is a unique feature where the card connects as a standard station (with any crypto, such as wpa), and then is set into wds mode. This isnt hooked into the system scripts at all and needs to be finished off. Have a look at tools/tools/net80211/scripts/setup.wds* and try some scenarios out. Andrew From owner-freebsd-net@FreeBSD.ORG Mon Aug 4 22:59:17 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28A521065686 for ; Mon, 4 Aug 2008 22:59:17 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id CDF7E8FC16 for ; Mon, 4 Aug 2008 22:59:16 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 31014 invoked by uid 399); 4 Aug 2008 22:59:15 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 4 Aug 2008 22:59:15 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <489789C1.1040509@FreeBSD.org> Date: Mon, 04 Aug 2008 15:59:13 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.16 (X11/20080726) MIME-Version: 1.0 To: Adrian Penisoara References: <4896A416.80602@FreeBSD.org> <78cb3d3f0808040630o7ad311a5r6da8f821d2bfe63a@mail.gmail.com> In-Reply-To: <78cb3d3f0808040630o7ad311a5r6da8f821d2bfe63a@mail.gmail.com> X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Ian Smith Subject: Re: permissions on /etc/namedb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2008 22:59:17 -0000 Adrian Penisoara wrote: > Hi, > > On Mon, Aug 4, 2008 at 12:57 PM, Ian Smith > wrote: > With the notable exception of making standard functions rndc trace and > querylog work, writing to the default file named.run, which named wants > to write in 'the working directory'. You'll have seen my solution to > that, touching named.run in case it doesn't exist then chown'ing it to > bind:wheel in /etc/rc.d/named, which I don't think endangers security. I think that is a reasonable solution for your situation, although I don't think it's appropriate to enable that by default. The default configuration is supposed to be a simple local resolver setup. Users who need more advanced features should be reading the docs. > I've not been able to find another solution, and there's no equivalent > of dump-file and statistics-file for the trace/querylog file (that I Query logging has its own log category, so you would do something like this: logging { channel queries_log { file "/var/log/queries.log"; severity debug; print-time yes; }; category queries { queries_log; }; }; The problem is that if you put that in your named.conf file it will log all queries when you start named. If there is interest I can add that to the default named.conf and add a knob to rc.conf to turn query logging on and off by default, but I'm hesitant to add that much complexity to something that is supposed to be simple but is already too complex. OTOH, one could argue that even for a local resolver there would be a non-trivial number of users who would want to enable logging of queries ... As for the equivalent functionality for the debug aspect of named.run, you're right, there is no equivalent. (FYI, the fact that queries are recorded in named.run when you bump the debug level is a side effect of the fact that queries are logged to the resolver category at debug level 1.) The problem is that the default_debug channel has a special property (only receives input when debug level is > 0) that cannot be reproduced with configuration options, and you cannot redefine the default logging channels. (but see below) > Quoting from a default distributed /etc/namedb/named.conf: > > options { > // Relative to the chroot directory, if any > directory "/etc/namedb"; > pid-file "/var/run/named/pid"; > dump-file "/var/dump/named_dump.db"; > statistics-file "/var/stats/named.stats"; > > You have to take into account that "directory" is used for any > non-absolute pathname specified in named.conf, including the "file" > clauses for master/slave zones. If you were to change it now then you > would break a lot of setups. Agreed. > I believe that the "working directory" and "root config directory" > concepts should have been dissociated. Also agreed. :) I plan to send some feature requests to the bind-users list based on the discussions in this thread. If you're interested in this topic I'd suggest that you follow the discussion on that list. I have an (unreviewed) patch to add a debug-only option at http://dougbarton.us/bind-debug-only-channel.diff if anyone wants to experiment with this. Using that patch I was able to do this: logging { channel our_debug { file "/var/log/named.run"; severity dynamic; print-time yes; debug-only yes; }; category default { default_syslog; our_debug; }; category unmatched { null; }; }; Which duplicates the default logging configuration except that you can now specify the location for the named.run file (or give it another file name, etc.). > Another idea would be to add a final "options { directory > "/var/run/named"; }; " statement at the end of the file -- from the BIND > sources it appears that there is a callback function which may pickup > this final statement in order to make it the current working directory > for the named process. The problem is that when you do a reconfig or a reload named won't be able to see its configuration file. > Oh, and in the idea that we should keep the default configuration as > simple as possible for the average user and for whatever scenario, here > is my proposal: > > dump-file "/var/run/named/named_dump.db"; > statistics-file "/var/run/named/named.stats"; This idea is not without merit, but I actually have them separated for a reason. The reason is sort of an "intermediate" level thing, but if you want to dump the db or the stats more than once and keep more than one version around it's more convenient to do this in a separate directory. Also the assumption is that /var/run is supposed to be cleaned out at each boot, and I wouldn't want to lose those files. > I'm not sure what happens when the user toggles tracing / query > logging (with rndc) -- where would these files go by default ? That depends on how you have syslog configured. If you have no other logging configured and you do 'rndc querylog' to toggle it on it will go to syslog with daemon.info. Unfortunately, FreeBSD's default configuration doesn't log that by default. One could argue that it should, but I really don't want to open that can of worms. If you want to give that a try you could change *.notice in syslog.conf for the /var/log/messages file to *.info, then /etc/rc.d/syslogd restart. (Or uncomment the all.log option, etc.) hth, Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Tue Aug 5 00:01:36 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA9BC106566B; Tue, 5 Aug 2008 00:01:36 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8EC3F8FC13; Tue, 5 Aug 2008 00:01:36 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m7501ZpY045639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Aug 2008 17:01:35 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4897985F.2030903@freebsd.org> Date: Mon, 04 Aug 2008 17:01:35 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Andrew Thompson References: <6b8e8f4f0808041513x2537c723vd575f0760cf53e02@mail.gmail.com> <20080804225840.GC6737@citylink.fud.org.nz> In-Reply-To: <20080804225840.GC6737@citylink.fud.org.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: freebsd-net@freebsd.org, David Cornejo Subject: Re: bridging wireless station X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2008 00:01:36 -0000 Andrew Thompson wrote: > On Mon, Aug 04, 2008 at 12:13:09PM -1000, David Cornejo wrote: > >> hi, >> >> i would like to bridge a wireless client to ethernet (in 8-CURRENT) - >> the last bug in the if_bridge man page says this is a no-no. >> > > The bridge man page needs to be updated as its possible to do this now. > > >> the question is whether this could be worked around - don't need the >> highest performance, so maybe netgraph or even a userland daemon would >> work. i don't have any ability to do anything at the access point end >> so some of the tunneling protocols are out >> > > The system supports wdslegacy and dwds modes. lecacy takes a static > bssid address to forward the traffic to, this mode can only be encrypted > with wep. > > dwds is a unique feature where the card connects as a standard station > (with any crypto, such as wpa), and then is set into wds mode. This > isnt hooked into the system scripts at all and needs to be finished off. > > Have a look at tools/tools/net80211/scripts/setup.wds* and try some > scenarios out. > A nit: dwds probably needs to be integrated with hostapd as there's some work involved that's best in a long-running application and I can't imagine anyone using it w/o some form of security. Having hostapd handle this would also simplify configuration. The integration work is straightforward and would be a good project for someone trying to learn about the wireless facilities. Sam From owner-freebsd-net@FreeBSD.ORG Tue Aug 5 00:17:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17D9B10656D7 for ; Tue, 5 Aug 2008 00:17:18 +0000 (UTC) (envelope-from dcornejo@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 96D748FC0A for ; Tue, 5 Aug 2008 00:17:17 +0000 (UTC) (envelope-from dcornejo@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so3043928fgb.35 for ; Mon, 04 Aug 2008 17:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=5kCNd4Oy+1TTt4DE+sfFRc5m0qSFCrALJakkjNXH8rw=; b=uwrNxi+CdSwEhJmnBz7wtgn+oB+pSuvRsf82osQqJLuKUeeqmad+XQ04D4AAcTIne+ 94v5L9yboXHyk3zq6Gt1w5FEcSY4LELj+JHW2FXIu5owCpKQzp7P6IgmXr9eLo4DwkjM 9eQs7lV80LjKqIjoKNxdQJHSHWmK/RxQncFes= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=m0pS0fRMQGl6cc87Z6SSB9sSpTxTem/+F+04LMlGTYzxW5E9ZNTxESajZGKlkxRmmD OVmEsVpr2349nGXkX2/FHAygS7WQvxD/ODvLaTYlgzgHCxJysTgRyUKxFIPbnthSVxlZ ZAbKcyEXKOU+vyyeo36K216YIlInkm3mQWDXE= Received: by 10.125.100.8 with SMTP id c8mr15713mkm.157.1217895436199; Mon, 04 Aug 2008 17:17:16 -0700 (PDT) Received: by 10.125.15.1 with HTTP; Mon, 4 Aug 2008 17:17:16 -0700 (PDT) Message-ID: <6b8e8f4f0808041717y1176d69ejc37b170f12349fe6@mail.gmail.com> Date: Mon, 4 Aug 2008 14:17:16 -1000 From: "David Cornejo" To: "Sam Leffler" In-Reply-To: <48978726.3060501@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6b8e8f4f0808041513x2537c723vd575f0760cf53e02@mail.gmail.com> <48978726.3060501@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: bridging wireless station X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2008 00:17:18 -0000 I have an existing AP that I have no control over (assume it doesn't support WDS) sitting on a clinic LAN. I have a second LAN that I need to bridge to the clinic LAN through a client wireless device. I had done this about a year ago using vtun (via an 'ethernet' tunnel), but then I had some control over the AP. thanks, dave c On Mon, Aug 4, 2008 at 12:48 PM, Sam Leffler wrote: > David Cornejo wrote: >> >> hi, >> >> i would like to bridge a wireless client to ethernet (in 8-CURRENT) - >> the last bug in the if_bridge man page says this is a no-no. >> >> the question is whether this could be worked around - don't need the >> highest performance, so maybe netgraph or even a userland daemon would >> work. i don't have any ability to do anything at the access point end >> so some of the tunneling protocols are out >> >> any thoughts are appreciated, >> >> > > The man page is out of date; HEAD has WDS support now so you can bridge > traffic that's 4-address encapsulated. You might try to be more clear what > you're trying to setup. > > Sam > > From owner-freebsd-net@FreeBSD.ORG Tue Aug 5 00:22:26 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4EE11065674 for ; Tue, 5 Aug 2008 00:22:26 +0000 (UTC) (envelope-from ady@ady.ro) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by mx1.freebsd.org (Postfix) with ESMTP id C22AD8FC17 for ; Tue, 5 Aug 2008 00:22:26 +0000 (UTC) (envelope-from ady@ady.ro) Received: by wf-out-1314.google.com with SMTP id 24so1981144wfg.7 for ; Mon, 04 Aug 2008 17:22:26 -0700 (PDT) Received: by 10.142.187.8 with SMTP id k8mr5158925wff.199.1217895745931; Mon, 04 Aug 2008 17:22:25 -0700 (PDT) Received: by 10.142.54.14 with HTTP; Mon, 4 Aug 2008 17:22:25 -0700 (PDT) Message-ID: <78cb3d3f0808041722qda84514j9f480860152215aa@mail.gmail.com> Date: Tue, 5 Aug 2008 02:22:25 +0200 From: "Adrian Penisoara" Sender: ady@ady.ro To: "Doug Barton" In-Reply-To: <489789C1.1040509@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4896A416.80602@FreeBSD.org> <78cb3d3f0808040630o7ad311a5r6da8f821d2bfe63a@mail.gmail.com> <489789C1.1040509@FreeBSD.org> X-Google-Sender-Auth: cee1f9046add38fa Cc: freebsd-net@freebsd.org, Ian Smith Subject: Re: permissions on /etc/namedb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2008 00:22:27 -0000 Hi, On Tue, Aug 5, 2008 at 12:59 AM, Doug Barton wrote: > > Adrian Penisoara wrote: >> >> Quoting from a default distributed /etc/namedb/named.conf: >> >> options { >> // Relative to the chroot directory, if any >> directory "/etc/namedb"; >> pid-file "/var/run/named/pid"; >> dump-file "/var/dump/named_dump.db"; >> statistics-file "/var/stats/named.stats"; >> >> You have to take into account that "directory" is used for any non-absolute pathname specified in named.conf, including the "file" clauses for master/slave zones. If you were to change it now then you would break a lot of setups. > > Agreed. > >> I believe that the "working directory" and "root config directory" concepts should have been dissociated. > > Also agreed. :) I plan to send some feature requests to the bind-users list based on the discussions in this thread. If you're interested in this topic I'd suggest that you follow the discussion on that list. I will try to :). > > I have an (unreviewed) patch to add a debug-only option at http://dougbarton.us/bind-debug-only-channel.diff if anyone wants to experiment with this. Using that patch I was able to do this: > > logging { > channel our_debug { > file "/var/log/named.run"; > severity dynamic; > print-time yes; > debug-only yes; > }; > category default { default_syslog; our_debug; }; > category unmatched { null; }; > }; > > Which duplicates the default logging configuration except that you can now specify the location for the named.run file (or give it another file name, etc.). > >> Another idea would be to add a final "options { directory "/var/run/named"; }; " statement at the end of the file -- from the BIND sources it appears that there is a callback function which may pickup this final statement in order to make it the current working directory for the named process. > > The problem is that when you do a reconfig or a reload named won't be able to see its configuration file. > >> Oh, and in the idea that we should keep the default configuration as simple as possible for the average user and for whatever scenario, here is my proposal: >> >> dump-file "/var/run/named/named_dump.db"; >> statistics-file "/var/run/named/named.stats"; > > This idea is not without merit, but I actually have them separated for a reason. The reason is sort of an "intermediate" level thing, but if you want to dump the db or the stats more than once and keep more than one version around it's more convenient to do this in a separate directory. Also the assumption is that /var/run is supposed to be cleaned out at each boot, and I wouldn't want to lose those files. Yep, you've got a point here. > >> I'm not sure what happens when the user toggles tracing / query logging (with rndc) -- where would these files go by default ? > > That depends on how you have syslog configured. If you have no other logging configured and you do 'rndc querylog' to toggle it on it will go to syslog with daemon.info. Unfortunately, FreeBSD's default configuration doesn't log that by default. One could argue that it should, but I really don't want to open that can of worms. If you want to give that a try you could change *.notice in syslog.conf for the /var/log/messages file to *.info, then /etc/rc.d/syslogd restart. (Or uncomment the all.log option, etc.) Umm, I'd rather add something along the following to /etc/syslog.conf (I usually do it for my nameservers): !named *.* /var/log/named.log And of course, one would accompany this with the following line in /etc/newsyslog.conf: /var/log/named.log 644 7 100 * J Regards, Adrian. From owner-freebsd-net@FreeBSD.ORG Tue Aug 5 00:24:34 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76165106564A for ; Tue, 5 Aug 2008 00:24:34 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4AF6E8FC17 for ; Tue, 5 Aug 2008 00:24:34 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from Macintosh-4.local ([10.0.0.194]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m750OX2D045801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Aug 2008 17:24:33 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <48979DC1.3040402@freebsd.org> Date: Mon, 04 Aug 2008 17:24:33 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: David Cornejo References: <6b8e8f4f0808041513x2537c723vd575f0760cf53e02@mail.gmail.com> <48978726.3060501@freebsd.org> <6b8e8f4f0808041717y1176d69ejc37b170f12349fe6@mail.gmail.com> In-Reply-To: <6b8e8f4f0808041717y1176d69ejc37b170f12349fe6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: freebsd-net@freebsd.org Subject: Re: bridging wireless station X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2008 00:24:34 -0000 Without WDS you'll need to bridge/tunnel at a different layer. Sam David Cornejo wrote: > I have an existing AP that I have no control over (assume it doesn't > support WDS) sitting on a clinic LAN. I have a second LAN that I need > to bridge to the clinic LAN through a client wireless device. I had > done this about a year ago using vtun (via an 'ethernet' tunnel), but > then I had some control over the AP. > > thanks, > dave c > > On Mon, Aug 4, 2008 at 12:48 PM, Sam Leffler wrote: >> David Cornejo wrote: >>> hi, >>> >>> i would like to bridge a wireless client to ethernet (in 8-CURRENT) - >>> the last bug in the if_bridge man page says this is a no-no. >>> >>> the question is whether this could be worked around - don't need the >>> highest performance, so maybe netgraph or even a userland daemon would >>> work. i don't have any ability to do anything at the access point end >>> so some of the tunneling protocols are out >>> >>> any thoughts are appreciated, >>> >>> >> The man page is out of date; HEAD has WDS support now so you can bridge >> traffic that's 4-address encapsulated. You might try to be more clear what >> you're trying to setup. >> >> Sam >> >> > _______________________________________________ > 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 Tue Aug 5 04:21:32 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E2FF1065672 for ; Tue, 5 Aug 2008 04:21:32 +0000 (UTC) (envelope-from bilouro@bilouro.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id E03C58FC0C for ; Tue, 5 Aug 2008 04:21:31 +0000 (UTC) (envelope-from bilouro@bilouro.com) Received: by nf-out-0910.google.com with SMTP id h3so1082235nfh.33 for ; Mon, 04 Aug 2008 21:21:30 -0700 (PDT) Received: by 10.210.46.12 with SMTP id t12mr550480ebt.64.1217908508151; Mon, 04 Aug 2008 20:55:08 -0700 (PDT) Received: by 10.210.13.15 with HTTP; Mon, 4 Aug 2008 20:55:08 -0700 (PDT) Message-ID: Date: Tue, 5 Aug 2008 00:55:08 -0300 From: "Victor Hugo Bilouro" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [GSoC - tcptest] Weekly Status Report #03 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2008 04:21:32 -0000 Hi People, I posted the tcptest weekly status report at freebsd wiki. http://wiki.freebsd.org/VictorBilouro/Release_0.1_Iteration_3 Other Links: http://wiki.freebsd.org/VictorBilouro/TCP-IP_regression_test_suite http://code.google.com/p/tcptest/downloads/list http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2008/bilouro_tcptest/src/scripts/tests -- Victor Hugo Bilouro FreeBSD! From owner-freebsd-net@FreeBSD.ORG Tue Aug 5 08:43:53 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43D2F1065676 for ; Tue, 5 Aug 2008 08:43:53 +0000 (UTC) (envelope-from viper@ertelecom.ru) Received: from mx1.ertelecom.ru (office.ertelecom.ru [212.33.232.253]) by mx1.freebsd.org (Postfix) with ESMTP id B2B2A8FC1D for ; Tue, 5 Aug 2008 08:43:52 +0000 (UTC) (envelope-from viper@ertelecom.ru) Received: from [10.100.10.235] ([10.100.10.235]) by mx1.ertelecom.ru with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Aug 2008 14:31:46 +0600 Message-ID: <48980FF1.3090308@ertelecom.ru> Date: Tue, 05 Aug 2008 14:31:45 +0600 From: =?UTF-8?B?0JrQvtGA0LrQvtC00LjQvdC+0LIg0JLQu9Cw0LTQuNC80LjRgA==?= Organization: ERtelecom User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) CC: "freebsd-net@freebsd.org" References: In-Reply-To: Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 05 Aug 2008 08:31:46.0066 (UTC) FILETIME=[B2585720:01C8F6D5] MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: arp - strange things X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: viper@ertelecom.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2008 08:43:53 -0000 I csup my server from Jul 14 to today sources and saw strange issue with arp table. Long description see below. Do you have the same "issue" on your own servers? Partial reverting=C2=A0 [1]http://www.freebsd.org/cgi/cvsweb.cgi= /src/sys/netinet/if_ether.c Revision 1.162.2.2 seems fix problem. #if 0 /* -current */ =C2=A0 =C2=A0/* Only call this once */ =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (firstpa= ss) { =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 sin.sin_addr.s_addr =3D isaddr.s_addr; EVENTHANDLER_INVOKE(route_arp_update_event, rt, =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 ar_sha(ah), (struct sockaddr *)&sin); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } #endif Long description Environment: uname -a FreeBSD monitor 7.0-STABLE FreeBSD 7.0-STABLE #5: Tue Aug=C2=A0 5 13:15:2= 4 YEKST 2008=C2=A0=C2=A0=C2=A0=C2=A0 root@monitor:/usr/obj/usr/src/sys/kern= el=C2=A0 amd64 Description: arp -an ? (10.100.8.118) at 00:1c:c4:3d:f0:b8 on bce1 [ethernet] ? (10.100.8.118) at (incomplete) on bce1 [ethernet] =2E............ ? (10.100.10.190) at 00:1a:4b:dd:84:a0 on bce1 [ethernet] ? (10.100.10.190) at (incomplete) on bce1 [ethernet] ? (10.100.10.190) at (incomplete) on bce1 [ethernet] ? (10.100.10.190) at (incomplete) on bce1 [ethernet] ? (10.100.10.190) at (incomplete) on bce1 [ethernet] =2E............... ? (212.xxx.xxx.xxx) at 00:1e:0b:91:15:08 on bce0 permanent [ethernet] = ? (212.xxx.xxx.xxx) at 00:1e:0b:91:15:08 on bce0 permanent [ethernet] = ? (212.xxx.xxx.xxx) at 00:1e:0b:91:15:08 on bce0 permanent [ethernet] = route monitor got message of size 296 on Tue Aug=C2=A0 5 14:08:23 2008 RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, flags: locks:=C2=A0 inits: sockaddrs: =C2=A010.100.10.190=C2=A0 bce1:0.1e.b.91.15.6 10.100.200.120 got message of size 296 on Tue Aug=C2=A0 5 14:09:11 2008 RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, flags: locks:=C2=A0 inits: sockaddrs: =C2=A010.100.10.190=C2=A0 bce1:0.1e.b.91.15.6 10.100.200.120 got message of size 296 on Tue Aug=C2=A0 5 14:09:12 2008 RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, flags: locks:=C2=A0 inits: sockaddrs: =C2=A010.100.10.190=C2=A0 bce1:0.1e.b.91.15.6 10.100.200.120 got message of size 296 on Tue Aug=C2=A0 5 14:09:12 2008 RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, flags: locks:=C2=A0 inits: sockaddrs: =C2=A010.100.10.190=C2=A0 bce1:0.1e.b.91.15.6 10.100.200.120 got message of size 296 on Tue Aug=C2=A0 5 14:09:17 2008 RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, flags: locks:=C2=A0 inits: sockaddrs: =C2=A010.100.10.190=C2=A0 bce1:0.1e.b.91.15.6 10.100.200.120 got message of size 296 on Tue Aug=C2=A0 5 14:09:17 2008 RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, flags: locks:=C2=A0 inits: sockaddrs: =C2=A010.100.10.190=C2=A0 bce1:0.1e.b.91.15.6 10.100.200.120 --=20 References 1. 3D"http://www.freebsd.org/cgi/cvs= From owner-freebsd-net@FreeBSD.ORG Tue Aug 5 09:23:48 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76766106566B for ; Tue, 5 Aug 2008 09:23:48 +0000 (UTC) (envelope-from viper@perm.raid.ru) Received: from smtp.ertelecom.ru (smtp.ertelecom.ru [212.33.232.210]) by mx1.freebsd.org (Postfix) with ESMTP id 2C1A78FC1E for ; Tue, 5 Aug 2008 09:23:47 +0000 (UTC) (envelope-from viper@perm.raid.ru) Received: from mail.raid.ru ([212.33.232.8]:43928) by smtp.ertelecom.ru with esmtp (Exim) id 1KQI5e-000HIC-JL for ; Tue, 05 Aug 2008 14:40:22 +0600 Received: from 212.33.232.121 (SquirrelMail authenticated user viper) by mail.raid.ru with HTTP; Tue, 5 Aug 2008 14:40:22 +0600 (YEKST) Message-ID: <17499.212.33.232.121.1217925622.squirrel@mail.raid.ru> Date: Tue, 5 Aug 2008 14:40:22 +0600 (YEKST) From: "Vladimir Korkodinov" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: (no subject) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: viper@perm.raid.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2008 09:23:48 -0000 I csup my server from Jul 14 to today sources and saw strange issue with arp table. Long description see below. Do you have the same "issue" on your own servers? Partial reverting http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/if_ether.c Revision 1.162.2.2 seems fix problem. +#if 0 /* -current */ /* Only call this once */ if (firstpass) { sin.sin_addr.s_addr = isaddr.s_addr; EVENTHANDLER_INVOKE(route_arp_update_event, rt, ar_sha(ah), (struct sockaddr *)&sin); } +#endif Long description: Environment: uname -a FreeBSD monitor 7.0-STABLE FreeBSD 7.0-STABLE #5: Tue Aug 5 13:15:24 YEKST 2008 root@monitor:/usr/obj/usr/src/sys/kernel amd64 Description: arp -an ? (10.100.8.118) at 00:1c:c4:3d:f0:b8 on bce1 [ethernet] ? (10.100.8.118) at (incomplete) on bce1 [ethernet] ............. ? (10.100.10.190) at 00:1a:4b:dd:84:a0 on bce1 [ethernet] ? (10.100.10.190) at (incomplete) on bce1 [ethernet] ? (10.100.10.190) at (incomplete) on bce1 [ethernet] ? (10.100.10.190) at (incomplete) on bce1 [ethernet] ? (10.100.10.190) at (incomplete) on bce1 [ethernet] ................ ? (212.xxx.xxx.xxx) at 00:1e:0b:91:15:08 on bce0 permanent [ethernet] ? (212.xxx.xxx.xxx) at 00:1e:0b:91:15:08 on bce0 permanent [ethernet] ? (212.xxx.xxx.xxx) at 00:1e:0b:91:15:08 on bce0 permanent [ethernet] route monitor got message of size 296 on Tue Aug 5 14:08:23 2008 RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 10.100.10.190 bce1:0.1e.b.91.15.6 10.100.200.120 got message of size 296 on Tue Aug 5 14:09:11 2008 RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 10.100.10.190 bce1:0.1e.b.91.15.6 10.100.200.120 got message of size 296 on Tue Aug 5 14:09:12 2008 RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 10.100.10.190 bce1:0.1e.b.91.15.6 10.100.200.120 got message of size 296 on Tue Aug 5 14:09:12 2008 RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 10.100.10.190 bce1:0.1e.b.91.15.6 10.100.200.120 got message of size 296 on Tue Aug 5 14:09:17 2008 RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 10.100.10.190 bce1:0.1e.b.91.15.6 10.100.200.120 got message of size 296 on Tue Aug 5 14:09:17 2008 RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 10.100.10.190 bce1:0.1e.b.91.15.6 10.100.200.120 -- Best regards Vladimir Korkodinov From owner-freebsd-net@FreeBSD.ORG Tue Aug 5 16:12:19 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20C581065675 for ; Tue, 5 Aug 2008 16:12:19 +0000 (UTC) (envelope-from proks@logos.sky.od.ua) Received: from logos.sky.od.ua (logos.sky.od.ua [81.25.224.11]) by mx1.freebsd.org (Postfix) with ESMTP id D4F978FC13 for ; Tue, 5 Aug 2008 16:12:18 +0000 (UTC) (envelope-from proks@logos.sky.od.ua) Received: from localhost (localhost [127.0.0.1]) by logos.sky.od.ua (Postfix) with ESMTP id 02324102C6B for ; Tue, 5 Aug 2008 19:12:18 +0300 (EEST) Date: Tue, 5 Aug 2008 19:12:17 +0300 (EEST) From: "Prokofiev S.P." To: freebsd-net@freebsd.org Message-ID: <20080805191158.F31591@logos.sky.od.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: ipfw nat/natd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2008 16:12:19 -0000 I have a problem at the scheme: ( gw ) <-----> ( nat_router ) <-----> ( https ) real.ip0 real.ip1 10.19.90.1 10.19.90.2 If I use ipfw+natd on nat_router then redirect to https server and to nat_router local address 10.19.90.1 is well, but if ipfw+nat - redirect to nat_router local address is fail. This is bug ? ipfw+nat schema - on nat_router - ipfw rules ipfw nat 1 config if vlan2 log redirect_port tcp 10.19.90.1:5000 5000 \ redirect_port tcp 10.19.90.2:443 443 ipfw add 500 nat 1 log ip from any to any via vlan2 // nat - iperf -s -p 5000 - on gw - iperf -p 5000 -c real.ip1 tcpdump -np -i vlan2 host real.ip0 18:36:08.170034 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:08.170093 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:11.170239 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:11.208523 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:11.208554 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:14.208712 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:14.448772 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:14.448802 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:17.449225 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:17.689771 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:17.689801 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:20.689736 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:20.944763 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:20.944794 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:23.945252 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 Thanks all! From owner-freebsd-net@FreeBSD.ORG Tue Aug 5 16:15:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FA5A106567A; Tue, 5 Aug 2008 16:15:27 +0000 (UTC) (envelope-from proks@logos.sky.od.ua) Received: from logos.sky.od.ua (logos.sky.od.ua [81.25.224.11]) by mx1.freebsd.org (Postfix) with ESMTP id 31CF38FC12; Tue, 5 Aug 2008 16:15:27 +0000 (UTC) (envelope-from proks@logos.sky.od.ua) Received: from localhost (localhost [127.0.0.1]) by logos.sky.od.ua (Postfix) with ESMTP id 493F7102CDE; Tue, 5 Aug 2008 18:51:33 +0300 (EEST) Date: Tue, 5 Aug 2008 18:51:33 +0300 (EEST) From: "Prokofiev S.P." To: freebsd-ipfw@freebsd.org Message-ID: <20080805181839.T23842@logos.sky.od.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: ipfw nat/natd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2008 16:15:27 -0000 I have a problem at the scheme: ( gw ) <-----> ( nat_router ) <-----> ( https ) real.ip0 real.ip1 10.19.90.1 10.19.90.2 If I use ipfw+natd on nat_router then redirect to https server and to nat_router local address 10.19.90.1 is well, but if ipfw+nat - redirect to nat_router local address is fail. This is bug ? ipfw+nat schema - on nat_router - ipfw rules ipfw nat 1 config if vlan2 log redirect_port tcp 10.19.90.1:5000 5000 \ redirect_port tcp 10.19.90.2:443 443 ipfw add 500 nat 1 log ip from any to any via vlan2 // nat - iperf -s -p 5000 - on gw - iperf -p 5000 -c real.ip1 tcpdump -np -i vlan2 host real.ip0 18:36:08.170034 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:08.170093 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:11.170239 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:11.208523 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:11.208554 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:14.208712 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:14.448772 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:14.448802 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:17.449225 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:17.689771 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:17.689801 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:20.689736 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:20.944763 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:20.944794 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:23.945252 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 Thanks all! From owner-freebsd-net@FreeBSD.ORG Tue Aug 5 16:15:37 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5DBA106564A for ; Tue, 5 Aug 2008 16:15:37 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 63E148FC19 for ; Tue, 5 Aug 2008 16:15:37 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KQPCB-00083x-V8 for freebsd-net@freebsd.org; Tue, 05 Aug 2008 16:15:36 +0000 Received: from mulderlab.f5.com ([205.229.151.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Aug 2008 16:15:35 +0000 Received: from atkin901 by mulderlab.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Aug 2008 16:15:35 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Mark Atkinson Date: Tue, 05 Aug 2008 09:15:20 -0700 Lines: 22 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mulderlab.f5.com User-Agent: KNode/0.10.5 Sender: news Subject: Re: [GSoC - tcptest] Weekly Status Report #03 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2008 16:15:37 -0000 Victor Hugo Bilouro wrote: > Hi People, > > I posted the tcptest weekly status report at freebsd wiki. > > http://wiki.freebsd.org/VictorBilouro/Release_0.1_Iteration_3 > > Other Links: > http://wiki.freebsd.org/VictorBilouro/TCP-IP_regression_test_suite > http://code.google.com/p/tcptest/downloads/list > http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2008/bilouro_tcptest/src/scripts/tests > Keep up the good work. Your package seems to be missing the psuedoipv4.py file/class however, and it's not in the ports/net/py-pcs port either. -- Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired); From owner-freebsd-net@FreeBSD.ORG Tue Aug 5 17:25:20 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6630106566B; Tue, 5 Aug 2008 17:25:20 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 07AAE8FC22; Tue, 5 Aug 2008 17:25:17 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id DAA17130; Wed, 6 Aug 2008 03:25:14 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 6 Aug 2008 03:25:13 +1000 (EST) From: Ian Smith To: Doug Barton In-Reply-To: <489789C1.1040509@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, Adrian Penisoara Subject: Re: permissions on /etc/namedb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2008 17:25:21 -0000 On Mon, 4 Aug 2008, Doug Barton wrote: > Adrian Penisoara wrote: > > On Mon, Aug 4, 2008 at 12:57 PM, Ian Smith > > wrote: > > With the notable exception of making standard functions rndc trace and > > querylog work, writing to the default file named.run, which named wants > > to write in 'the working directory'. You'll have seen my solution to > > that, touching named.run in case it doesn't exist then chown'ing it to > > bind:wheel in /etc/rc.d/named, which I don't think endangers security. > > I think that is a reasonable solution for your situation, although I > don't think it's appropriate to enable that by default. The default > configuration is supposed to be a simple local resolver setup. Users > who need more advanced features should be reading the docs. Over and over :) I've *almost* got my head around the logging section, after initially resisting the idea of using rndc trace being 'advanced'. > > I've not been able to find another solution, and there's no equivalent > > of dump-file and statistics-file for the trace/querylog file (that I > > Query logging has its own log category, so you would do something like > this: > > logging { > channel queries_log { > file "/var/log/queries.log"; > severity debug; print-time yes; > }; > category queries { queries_log; }; > }; > > The problem is that if you put that in your named.conf file it will > log all queries when you start named. If there is interest I can add > that to the default named.conf and add a knob to rc.conf to turn query > logging on and off by default, but I'm hesitant to add that much Even with option 'querylog no' in .conf? Anyhow, manageable with rndc. > complexity to something that is supposed to be simple but is already > too complex. OTOH, one could argue that even for a local resolver > there would be a non-trivial number of users who would want to enable > logging of queries ... I was starting to wonder if I was the only one who ever used it, though only wanting it on when and as required. Same with debug logging; I'm finding it really handy just now, checking a new setup for a handful of auth zones, but wouldn't usually want to know except during 'issues'. > As for the equivalent functionality for the debug aspect of named.run, > you're right, there is no equivalent. (FYI, the fact that queries are > recorded in named.run when you bump the debug level is a side effect > of the fact that queries are logged to the resolver category at debug > level 1.) The problem is that the default_debug channel has a special > property (only receives input when debug level is > 0) that cannot be > reproduced with configuration options, and you cannot redefine the > default logging channels. (but see below) Funny thing is, you can redefine these, modulo the exception below, despite what the ARM says. Late last night, before reading this from you this morning, I'd found http://www.cymru.com/Documents/secure-bind-template.html showing redefining the default_syslog channel, amidst a useful example of using channels and categories - where I find the ARM a wee bit terse - so I thought, why not try: logging { channel default_debug { file "/var/log/named.run"; severity dynamic; print-time yes; print-category yes; // education .. print-severity yes; // ditto }; category default { default_syslog; default_debug; }; }; which works fine - except as you say, it logs, tolerably minimally, even when notrace / debug level is 0. And using that I'm starting to figure out which debug messages come from which categories at what levels, so it's very useful at the moment, though obviously a gross workaround .. Adrian Penisoara wrote: > > Quoting from a default distributed /etc/namedb/named.conf: > > > > options { > > // Relative to the chroot directory, if any > > directory "/etc/namedb"; > > pid-file "/var/run/named/pid"; > > dump-file "/var/dump/named_dump.db"; > > statistics-file "/var/stats/named.stats"; > > > > You have to take into account that "directory" is used for any > > non-absolute pathname specified in named.conf, including the "file" > > clauses for master/slave zones. If you were to change it now then you > > would break a lot of setups. > > Agreed. > > > I believe that the "working directory" and "root config directory" > > concepts should have been dissociated. > > Also agreed. :) I plan to send some feature requests to the > bind-users list based on the discussions in this thread. If you're > interested in this topic I'd suggest that you follow the discussion on > that list. Wish I had the time, maybe next month. If there were a 'logdirectory' option, defaulting to 'directory' as now, that would solve this whole POLA issue for stragglers from bind 4 and others expecting debug and query logging to work as per rndc(8) in an out-of-the-box setup. > I have an (unreviewed) patch to add a debug-only option at > http://dougbarton.us/bind-debug-only-channel.diff if anyone wants to > experiment with this. Using that patch I was able to do this: > > logging { > channel our_debug { > file "/var/log/named.run"; > severity dynamic; > print-time yes; > debug-only yes; > }; > category default { default_syslog; our_debug; }; > category unmatched { null; }; > }; > > Which duplicates the default logging configuration except that you can > now specify the location for the named.run file (or give it another > file name, etc.). So debug-only would give the same functionality as that default_debug special property (log if trace > 0) to other channels as desired, right? > > Another idea would be to add a final "options { directory > > "/var/run/named"; }; " statement at the end of the file -- from the BIND > > sources it appears that there is a callback function which may pickup > > this final statement in order to make it the current working directory > > for the named process. > > The problem is that when you do a reconfig or a reload named won't be > able to see its configuration file. > > > Oh, and in the idea that we should keep the default configuration as > > simple as possible for the average user and for whatever scenario, here > > is my proposal: > > > > dump-file "/var/run/named/named_dump.db"; > > statistics-file "/var/run/named/named.stats"; > > This idea is not without merit, but I actually have them separated for > a reason. The reason is sort of an "intermediate" level thing, but if > you want to dump the db or the stats more than once and keep more than > one version around it's more convenient to do this in a separate > directory. Also the assumption is that /var/run is supposed to be > cleaned out at each boot, and I wouldn't want to lose those files. Well I'm comfortable with the directory setup as is, only excepting the desire expressed here for somewhere standard as supplied that bind can write its other log files to. So far I only know about named.run and named.recursing (which I also tried, because it was there :) > > I'm not sure what happens when the user toggles tracing / query > > logging (with rndc) -- where would these files go by default ? Currently, named tries to open named.run in its 'working directory', ie directory "[/var/named]/etc/namedb" by default, owned by root. Try 'rndc trace' and tail /var/log/messages and you may see "isc_log_open 'named.run' failed: permission denied" ono, at bind 9.3.4-P1 anyway. > That depends on how you have syslog configured. If you have no other > logging configured and you do 'rndc querylog' to toggle it on it will > go to syslog with daemon.info. Unfortunately, FreeBSD's default > configuration doesn't log that by default. One could argue that it > should, but I really don't want to open that can of worms. If you want > to give that a try you could change *.notice in syslog.conf for the > /var/log/messages file to *.info, then /etc/rc.d/syslogd restart. (Or > uncomment the all.log option, etc.) Scary :) Thanks for the detailed explanations, Doug. Much appreciated. cheers, Ian PS sorry about your direct mail bouncing off our ancient mailserver's antispam (mis)config. To be retired any day now, but fixed anyway. From owner-freebsd-net@FreeBSD.ORG Tue Aug 5 19:51:32 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75C4D106566C for ; Tue, 5 Aug 2008 19:51:32 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (capeta.freebsdbrasil.com.br [201.48.151.3]) by mx1.freebsd.org (Postfix) with SMTP id 84A3C8FC17 for ; Tue, 5 Aug 2008 19:51:31 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 29075 invoked from network); 5 Aug 2008 16:51:29 -0300 Received: by simscan 1.1.0 ppid: 29010, pid: 29011, t: 2.3074s scanners: clamav: 0.91.1/m: spam: 3.1.1 X-Spam-Checker-Version: SpamAssassin: -last, FreeBSD Brasil LTDA rulesets: Yes X-Spam-Status: No, hits=-2.0 required=3.7 Received: from unknown (HELO claire.bh.freebsdbrasil.com.br) (201.48.151.226) by capeta.freebsdbrasil.com.br with SMTP; 5 Aug 2008 16:51:27 -0300 Message-ID: <4898AF05.5020505@freebsdbrasil.com.br> Date: Tue, 05 Aug 2008 16:50:29 -0300 From: Patrick Tracanelli Organization: FreeBSD Brasil LTDA User-Agent: Thunderbird 2.0.0.0 (X11/20070612) MIME-Version: 1.0 To: Mike Makonnen References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> <48922E9D.1020507@elischer.org> <4893328C.2040105@freebsdbrasil.com.br> <4894447C.3000800@wubethiopia.com> <48945A79.50300@wubethiopia.com> <48970597.3030407@freebsdbrasil.com.br> In-Reply-To: <48970597.3030407@freebsdbrasil.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2008 19:51:32 -0000 Patrick Tracanelli escreveu: > Mike Makonnen escreveu: >> Mike Makonnen wrote: >>> Patrick Tracanelli wrote: >>>> >>>> To let you know of my current (real world) tests: >>>> >>>> - Wireless Internet Provider 1: >>>> - 4Mbit/s of Internet Traffic >>>> - Classifying default protocols + soulseek + ssh >>>> - Classifying 100Mbit/s of dump over ssh >>>> >>>> Results in: >>>> No latency added, very low CPU usage, no packets dropping. >>>> >>>> - Wireless ISP 2: >>>> - 21 Mbit/s of Internet Traffic >>>> - Classifying default protocols + soulseek + ssh >>>> >>>> Results in: >>>> No tcp or udp traffic at all; everything that gets diverted >>>> never comes out of the divert socket, and ipfw-classifyd logs >>>> >>>> Aug 1 12:07:35 ourofino last message repeated 58 times >>>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: bittorrent >>>> (rule 50000) >>>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: edonkey >>>> (rule 50000) >>>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: fasttrack >>>> (rule 50000) >>>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: gnutella >>>> (rule 1000) >>>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: soulseek >>>> (rule 50000) >>>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: ssh >>>> (rule 50000) >>>> Aug 1 12:18:28 ourofino ipfw-classifyd: unable to write to divert >>>> socket: Operation not permitted >>>> Aug 1 12:18:50 ourofino last message repeated 90 times >>> >>> Hmmm... this part means that the call to sendto(2) to write the >>> packet back into network stack failed. This explains why you are not >>> seein g any traffic comming back out of the divert socket, but I >>> don't see why it would suddenly fail with a permission error. Could >>> this be a kernel bug? >>>> Aug 1 12:18:51 ourofino ipfw-classifyd: packet dropped: input queue >>>> full >>>> Aug 1 12:19:11 ourofino last message repeated 94 times >>>> >>>> Raised queue len a lot (up to 40960), when the application starts it >>>> uses up to 25% CPU and a second after that, CPU usage gets lower the >>>> 0.1%. >>> >>> This looks like a deadlock. If it weren't able to process packets >>> fast enough the cpu usage should be high even as it's spewing "packet >>> dropped" messages. Can you send me some more information like memory >>> usage and the firewall script you are using? How much of the >>> 21Mbits/s of traffic is P2P? If you reduce the number of protocols >>> you are trying to match against does the behavior change? Using >>> netstat -w1 -I can you tell me how many packets per second >>> we're talking about for 4Mbits/s and 21Mbit/s? Also, the timestamps >>> from the log file seem to show that the daemon is running for approx. >>> 34 sec. before the first "unable to write to write to divert socket" >>> message. Is it passing traffic during this time? Thanks. >>> >>> I've uploaded a newer version. Can you try that also please. It >>> includes: >>> o SIGHUP forces it to re-read its configuration file >>> o rc.d script >>> o minor optimization (calls pthread_cond_signal with the mutex >>> unlocked) >>> o code cleanup >>> >>> Also, for your convenience I have attached a patch against the >>> earlier version that removes a debugging printf that should remove >>> spammage to your log files (the current version has it removed already). >>> >> >> Ooops, a few minutes after I sent this email I found a couple of bugs >> (one major, and one minor). They were in the original tarball as well >> as the newer one I uploaded earlier today. I've uploaded a fixed >> version of the code. Can you try that instead please. >> >> Also, to help track down performance issues I've modified the Makefile >> to build a profiled version of the application so you can use gprof(1) >> to figure out where any problems lie. >> >> Cheers. >> > > On gcc 3.4.6, -Wno-pointer-sign compiler switch is unknown and > therefore compiling fails: > > cc -O2 -fno-strict-aliasing -pipe -O2 -pipe -pg -g -Wsystem-headers > -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type > -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align > -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs > -Wredundant-decls -Wno-pointer-sign -c classifyd.c > cc1: error: unrecognized command line option "-Wno-pointer-sign" > *** Error code 1 > > Stop in /usr/home/setup/ipfw-classifyd. > > If removed, does compile fine. > > On amd64 does not compile: > > cc -O2 -fno-strict-aliasing -pipe -O2 -pipe -pg -g -Wsystem-headers > -Werror -Wall -Wno- > format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer > -arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow > -Wcast-align -Wunus > ed-parameter -Wchar-subscripts -Winline -Wnested-externs > -Wredundant-decls -Wno-pointer > -sign -fPIC -pipe -c classifyd.c > cc1: warnings being treated as errors > classifyd.c: In function 'write_pthread': > classifyd.c:813: warning: format '%d' expects type 'int', but argument 4 > has type 'size_ > t' > *** Error code 1 > > The rules Im running: > > 00001 1379 320702 fwd 192.168.100.11 ip from any to { > 201.91.17.200/29 or dst-ip 189.44.216.168/29 } out via fxp0 > 00002 0 0 fwd 192.168.100.11 ip from any to { > 201.91.17.200/29 or dst-ip 189.44.216.168/29 } out via fxp2 > 00003 39137 7760042 fwd 189.52.140.1 ip from 189.52.140.10 to any out > via fxp0 > 00004 34462 10801535 fwd 189.52.140.3 ip from 189.52.140.11 to any out > via fxp0 > 00005 68780 29374414 fwd 189.52.140.1 ip from 189.52.140.18 to any out > via fxp0 > 00006 12154 2003678 fwd 189.52.140.3 ip from 189.52.140.19 to any out > via fxp0 > 00500 4741 770166 divert 7777 tcp from any to any via fxp0 > 00501 172 38599 divert 7777 udp from any to any via fxp0 > 49999 823215 453482966 allow ip from any to any > 65535 0 0 allow ip from any to any > > Memory usage while running classifyd: > > Mem: 67M Active, 27M Inact, 44M Wired, 24K Cache, 111M Buf, 859M Free > Swap: 1024M Total, 1024M Free > > classifyd's CPU usage: > > 5198 root 3 20 0 6132K 5420K kserel 1:14 24.52% > ipfw-classifyd > > System load averga for 5 minutes is 0.2 while not running classifyd and > 0.8 while running. > > Logs with the latest (downloaded a few minutes ago) code: > > Aug 4 10:15:29 ourofino ipfw-classifyd: Loaded Protocol: bittorrent > (rule 50000) > Aug 4 10:15:29 ourofino ipfw-classifyd: Loaded Protocol: edonkey (rule > 50000) > Aug 4 10:15:29 ourofino ipfw-classifyd: Loaded Protocol: fasttrack > (rule 50000) > Aug 4 10:15:29 ourofino ipfw-classifyd: Loaded Protocol: gnutella (rule > 50000) > Aug 4 10:15:29 ourofino ipfw-classifyd: Loaded Protocol: soulseek (rule > 50000) > Aug 4 10:15:29 ourofino ipfw-classifyd: Loaded Protocol: ssh (rule 50000) > Aug 4 10:15:36 ourofino ipfw-classifyd: packet dropped: input queue full > Aug 4 10:16:07 ourofino last message repeated 1594 times > Aug 4 10:16:19 ourofino last message repeated 766 times > > I miss the debug lines! ;D > > # netstat -w1 -I fxp0 > input (fxp0) output > packets errs bytes packets errs bytes colls > 535 0 286009 515 0 165965 0 > 416 0 347448 456 0 153585 0 > 444 0 309008 449 0 185087 0 > 493 0 190090 474 0 202637 0 > 547 0 197882 562 0 233751 0 > 409 0 288318 461 0 249421 0 > 434 0 173193 464 0 261512 0 > 437 0 246516 450 0 258908 0 > 458 0 200348 481 0 157800 0 > 423 0 250006 427 0 97723 0 > 367 0 261323 349 0 96405 0 > 592 0 178843 556 0 91032 0 > 450 0 248174 432 0 112650 0 > 390 0 244258 349 0 106532 0 > 442 0 303159 392 0 125664 0 > 407 0 237804 350 0 84367 0 > 460 0 207586 456 0 86633 0 > 364 0 200758 366 0 99798 0 > 313 0 241031 325 0 85746 0 > 463 0 248284 470 0 113385 0 > > With above protocols, wont matter if I run with the default queue len, > with -q 4096 or -q 40960. Its always never enough and I get the "input > queue full" logs. > > However, if I remove add only 1 or 2 protocols (tried bittorrend only > and later, edonkey only), things do work fine, for a few seconds, but than: > > Aug 4 10:22:58 ourofino ipfw-classifyd: Loaded Protocol: bittorrent > (rule 50000) > Aug 4 10:24:32 ourofino ipfw-classifyd: Loaded Protocol: bittorrent > (rule 50000) > Aug 4 10:28:02 ourofino ipfw-classifyd: unable to write to divert > socket: Invalid argument > Aug 4 10:28:33 ourofino last message repeated 20 times > Aug 4 10:29:03 ourofino last message repeated 18 times > Aug 4 10:29:05 ourofino kernel: pid 5654 (ipfw-classifyd), uid 0: > exited on signal 6 (core dumped) > Aug 4 10:30:06 ourofino ipfw-classifyd: Loaded Protocol: bittorrent > (rule 50000) > Aug 4 10:30:08 ourofino ipfw-classifyd: packet dropped: input queue full > Aug 4 10:30:09 ourofino last message repeated 186 times > Aug 4 10:30:17 ourofino ipfw-classifyd: unable to write to divert > socket: Invalid argument > Aug 4 10:30:27 ourofino last message repeated 2 times > Aug 4 10:32:43 ourofino ipfw-classifyd: Loaded Protocol: edonkey (rule > 50000) > Aug 4 10:33:04 ourofino ipfw-classifyd: unable to write to divert > socket: Invalid argument > Aug 4 10:33:22 ourofino last message repeated 11 times > Aug 4 10:33:23 ourofino kernel: pid 5901 (ipfw-classifyd), uid 0: > exited on signal 6 (core dumped) > > I get the " unable to write to divert socket: Invalid argument" > constantly and when classifyd dies (core dump with signal 6) I get the > following debug output: > > Assertion failed: (datalen >= 0), function classify_pthread, file > classifyd.c, line 646. > > What other useful output I can send you? > I tried figuring out myself some extra clues, but still stucked where I began. -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316601@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" From owner-freebsd-net@FreeBSD.ORG Wed Aug 6 01:21:52 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB0861065682 for ; Wed, 6 Aug 2008 01:21:52 +0000 (UTC) (envelope-from bilouro@bilouro.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 7733B8FC13 for ; Wed, 6 Aug 2008 01:21:51 +0000 (UTC) (envelope-from bilouro@bilouro.com) Received: by nf-out-0910.google.com with SMTP id h3so1354506nfh.33 for ; Tue, 05 Aug 2008 18:21:50 -0700 (PDT) Received: by 10.210.86.10 with SMTP id j10mr1808710ebb.78.1217985710606; Tue, 05 Aug 2008 18:21:50 -0700 (PDT) Received: by 10.210.13.15 with HTTP; Tue, 5 Aug 2008 18:21:50 -0700 (PDT) Message-ID: Date: Tue, 5 Aug 2008 22:21:50 -0300 From: "Victor Hugo Bilouro" To: "Mark Atkinson" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-net@freebsd.org Subject: Re: [GSoC - tcptest] Weekly Status Report #03 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2008 01:21:52 -0000 On Tue, Aug 5, 2008 at 1:15 PM, Mark Atkinson wrote: > Victor Hugo Bilouro wrote: > >> Hi People, >> >> I posted the tcptest weekly status report at freebsd wiki. >> >> http://wiki.freebsd.org/VictorBilouro/Release_0.1_Iteration_3 >> >> Other Links: >> http://wiki.freebsd.org/VictorBilouro/TCP-IP_regression_test_suite >> http://code.google.com/p/tcptest/downloads/list >> > http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2008/bilouro_tcptest/src/scripts/tests >> > > Keep up the good work. Your package seems to be missing the psuedoipv4.py > file/class however, and it's not in the ports/net/py-pcs port either. > > -- > Mark Atkinson > atkin901@yahoo.com > (!wired)?(coffee++):(wired); > > _______________________________________________ > 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" > Ohh.. tks! The class psuedoipv4 is on ipv4.py only in my sources ( /src/pcs/... ) There are a changed version of pcs inside my sources, so, copy it to ports work folder and then setup.py. To be true, my version have only few changes merged from the latest version of PCS(gnn repository). Unfortunaly we can't work with the latest version of pcs(from gnn repo) because it don't work with its dependencies of ports right now. We choose work on that after gsoc. Best! -- Victor Hugo Bilouro FreeBSD! From owner-freebsd-net@FreeBSD.ORG Wed Aug 6 05:15:48 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3B3E106564A for ; Wed, 6 Aug 2008 05:15:48 +0000 (UTC) (envelope-from netslists@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id 597218FC19 for ; Wed, 6 Aug 2008 05:15:48 +0000 (UTC) (envelope-from netslists@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1388936ywe.13 for ; Tue, 05 Aug 2008 22:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:content-type :content-transfer-encoding; bh=05xtHpLU47zl6bVdltiSAGj2tLyJIXbPOtmSedRJhqM=; b=PgmHvOUGO4R5FzZJ0oJ01HvmFI+QrfkYl63Uylb07x+STwujB9s7+rxgYZsgPzB5zA ObtVbZ+n9quup4l7PKV/HkhVmmVP9sp0jEgSuUpxEa64yF3u4498Dj1+0HvLMKpmtyMo qbiaPr7RggMqIrcS7sUw/xdKsBXfbp68Hd7xM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; b=SY4/ZPkVMCc05N3kmQ/jRt2fXAMpwpsvJoigOHUSUajkQfrWDdUzO99Kv3WftnovVb PLEoTXLxqd1YIraf53ZOaukAGA0y8Y1lWqXTXP+pPD0gV5NSNFoERuefhs9yqywcl1W8 Qc+UDzWZHhGgk8JcqhJMSlT7lL7uBKUv3aLMM= Received: by 10.150.202.8 with SMTP id z8mr2606025ybf.223.1217998188733; Tue, 05 Aug 2008 21:49:48 -0700 (PDT) Received: from ?192.168.12.8? ( [97.101.40.241]) by mx.google.com with ESMTPS id 5sm1308795ywd.8.2008.08.05.21.49.46 (version=SSLv3 cipher=RC4-MD5); Tue, 05 Aug 2008 21:49:47 -0700 (PDT) Message-ID: <48992D64.1020502@gmail.com> Date: Wed, 06 Aug 2008 00:49:40 -0400 From: Sten Daniel Soersdal User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "freebsd-net@FreeBSD.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Motin , Archie Cobbs Subject: ng_ppp: question about "bandwidth" parameter. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2008 05:15:48 -0000 Is there a reason NG_PPP_MAX_BANDWIDTH is limited to a total of 10 Mbit? If any of the links are faster than 10 Mbit, will i achieve same end result by dividing Bandwidth by say 10? That is, for every 10 Mbit physical link i configure ng_ppp to 1 Mbit? Or could i change the constant to the equivalent of 100 Mbit/s without the risk of breaking anything? The reason i ask is I noticed in ng_ppp.c (1.70.2.3) in function ng_ppp_mp_strategy(..) that ng_ppp also takes into account queued packets and the additional latency that would implicate. -- Sten Daniel Soersdal From owner-freebsd-net@FreeBSD.ORG Wed Aug 6 06:42:54 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D4501065679 for ; Wed, 6 Aug 2008 06:42:54 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 999B18FC1E for ; Wed, 6 Aug 2008 06:42:53 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14) with ESMTPA id 187095364; Wed, 06 Aug 2008 09:42:52 +0300 Message-ID: <489947EB.4010606@FreeBSD.org> Date: Wed, 06 Aug 2008 09:42:51 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: Sten Daniel Soersdal References: <48992D64.1020502@gmail.com> In-Reply-To: <48992D64.1020502@gmail.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "freebsd-net@FreeBSD.org" , Archie Cobbs Subject: Re: ng_ppp: question about "bandwidth" parameter. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2008 06:42:54 -0000 Sten Daniel Soersdal wrote: > Is there a reason NG_PPP_MAX_BANDWIDTH is limited to a total of 10 Mbit? AFAIR the only reason is 32bit integer math overflow protection. Probably it is the time now to think about 64 bits. > If any of the links are faster than 10 Mbit, will i achieve same end > result by dividing Bandwidth by say 10? That is, for every 10 Mbit > physical link i configure ng_ppp to 1 Mbit? > Or could i change the constant to the equivalent of 100 Mbit/s without > the risk of breaking anything? I am not sure. You should first check value ranges in all math operations. > The reason i ask is I noticed in ng_ppp.c (1.70.2.3) in function > ng_ppp_mp_strategy(..) that ng_ppp also takes into account queued > packets and the additional latency that would implicate. Yes. If you divide all speeds on 10 it will break link queue length calculation. So until traffic will be below specified constants it will work more or less correct. Above it node will think that queues are constantly overflowed and link balancing algorithm will become ineffective. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Wed Aug 6 18:47:17 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2ADE1065670 for ; Wed, 6 Aug 2008 18:47:17 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (unknown [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6BE5F8FC32 for ; Wed, 6 Aug 2008 18:47:17 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 4FADD28448 for ; Thu, 7 Aug 2008 02:47:16 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 9D5E1ED9CC2; Thu, 7 Aug 2008 02:47:15 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id kSQXFX4IpaHn; Thu, 7 Aug 2008 02:47:10 +0800 (CST) Received: from charlie.delphij.net (71.5.7.139.ptr.us.xo.net [71.5.7.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id A55E4EB0A8E; Thu, 7 Aug 2008 02:47:09 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=nFajAXKYjZrHUHQ0QBE5aTYub7kIqAanzMNKHjGZUfXWuIVBGgQoCkZjMoYOl3Ckb SXSdamrAUHzK5DY01M4Ng== Message-ID: <4899F1AB.8080409@delphij.net> Date: Wed, 06 Aug 2008 11:47:07 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.16 (X11/20080725) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.95.6 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Quake Lee Subject: Routing: local link vs VPN provided route X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2008 18:47:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, We have recently working on an OpenVPN scenario and we have found that when there is a locally linked network, the route provided by OpenVPN would not work: - - Local network uses 192.168.1.0/24 network (thus we have a flags 'UC' route) - - Upon connection, the VPN would provide a route to 192.168.1.0/24 through the tun0 device. It seems, however, that the packets would just go to local network. Is it possible to get packets to non-conflicting IP addresses (i.e. only exist in either local network, or remote VPN'ed network) to go through the tun0 device? (Of course it's possible to configure the remote network or local network as 192.168.0.0/24, just curious about this scenario - do we have a switch or something?) Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkiZ8asACgkQi+vbBBjt66DNHQCgn1aH3X05XnS1jS4Bf+NWotT8 BhkAoJLDo48H8KNGyHauXvoHjeqEEWiJ =ibIF -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Wed Aug 6 19:00:42 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA8FE106567F for ; Wed, 6 Aug 2008 19:00:42 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 733BA8FC2E for ; Wed, 6 Aug 2008 19:00:42 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.ws.pitbpa0.priv.collaborativefusion.com (vanquish.ws.pitbpa0.priv.collaborativefusion.com [192.168.2.162]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Wed, 06 Aug 2008 14:50:26 -0400 id 00056453.4899F273.00016122 Date: Wed, 6 Aug 2008 14:50:31 -0400 From: Bill Moran To: d@delphij.net Message-Id: <20080806145031.9c94326a.wmoran@collaborativefusion.com> In-Reply-To: <4899F1AB.8080409@delphij.net> References: <4899F1AB.8080409@delphij.net> Organization: Collaborative Fusion X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Xin LI , Quake Lee Subject: Re: Routing: local link vs VPN provided route X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2008 19:00:42 -0000 In response to Xin LI : > > We have recently working on an OpenVPN scenario and we have found that > when there is a locally linked network, the route provided by OpenVPN > would not work: > > - - Local network uses 192.168.1.0/24 network (thus we have a flags 'UC' > route) > > - - Upon connection, the VPN would provide a route to 192.168.1.0/24 > through the tun0 device. > > It seems, however, that the packets would just go to local network. Is > it possible to get packets to non-conflicting IP addresses (i.e. only > exist in either local network, or remote VPN'ed network) to go through > the tun0 device? Any hack you would do to make this work is going to be unreliable at best. Renumber your network so that routing can work as designed. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023 From owner-freebsd-net@FreeBSD.ORG Wed Aug 6 19:31:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B6661065676 for ; Wed, 6 Aug 2008 19:31:41 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.freebsd.org (Postfix) with ESMTP id 2E2418FC15 for ; Wed, 6 Aug 2008 19:31:40 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id BD90C3721C0A; Wed, 6 Aug 2008 12:14:29 -0700 (PDT) Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Mail Security) with ESMTP id 9E351280C5; Wed, 6 Aug 2008 12:14:29 -0700 (PDT) X-AuditID: 11807130-aab92bb000000ead-39-4899f8151287 Received: from cswiger1.apple.com (cswiger1.apple.com [17.227.140.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay11.apple.com (Apple SCV relay) with ESMTP id 7A8E2280B4; Wed, 6 Aug 2008 12:14:29 -0700 (PDT) Message-Id: From: Chuck Swiger To: Bill Moran In-Reply-To: <20080806145031.9c94326a.wmoran@collaborativefusion.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 6 Aug 2008 12:14:29 -0700 References: <4899F1AB.8080409@delphij.net> <20080806145031.9c94326a.wmoran@collaborativefusion.com> X-Mailer: Apple Mail (2.928.1) X-Brightmail-Tracker: AAAAAA== Cc: freebsd-net@freebsd.org, d@delphij.net, Quake Lee , Xin LI Subject: Re: Routing: local link vs VPN provided route X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2008 19:31:41 -0000 Hi, all-- On Aug 6, 2008, at 11:50 AM, Bill Moran wrote: >> It seems, however, that the packets would just go to local >> network. Is >> it possible to get packets to non-conflicting IP addresses (i.e. only >> exist in either local network, or remote VPN'ed network) to go >> through >> the tun0 device? > > Any hack you would do to make this work is going to be unreliable at > best. > > Renumber your network so that routing can work as designed. Bill's advice is solid, but there are some other alternatives available. You could set up individual host routes (ie, a route with a /32 netmask) which go over tun0 rather than defaulting to your local ethernet link, for the things you want to access remotely. The other alternative is to set up OpenVPN in bridging mode: http://openvpn.net/index.php/documentation/faq.html#bridge1 http://openvpn.net/index.php/documentation/miscellaneous/ethernet-bridging.html This isn't a recommended configuration for many purposes, as it is more efficient to use explicit routing between subnets when you need to cross the VPN link, rather than simply sending everything over that link as in a bridge, but bridging works better with Samba, ZeroConf/ Bonjour, and other things which use network broadcasts to find things on the "local" subnet. Regards, -- -Chuck From owner-freebsd-net@FreeBSD.ORG Wed Aug 6 21:20:17 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CFBB1065675 for ; Wed, 6 Aug 2008 21:20:17 +0000 (UTC) (envelope-from info@tecodryer.com) Received: from tember.borusantelekom.com (mail.bnet.net.tr [213.194.65.162]) by mx1.freebsd.org (Postfix) with ESMTP id 31B2D8FC14 for ; Wed, 6 Aug 2008 21:20:15 +0000 (UTC) (envelope-from info@tecodryer.com) Received: (qmail 4211 invoked by uid 89); 6 Aug 2008 21:12:24 -0000 Received: from unknown (HELO erkan-e90bf8060) (78.161.127.33) by 0 with SMTP; 6 Aug 2008 21:12:24 -0000 From: "TECO DRYER" To: freebsd-net@freebsd.org Message-Id: <20080806212016.31B2D8FC14@mx1.freebsd.org> Date: Wed, 6 Aug 2008 21:20:15 +0000 (UTC) Subject: Teco Industry is in the business of corn, wheat, paddy, and X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2008 21:20:17 -0000 vegetable dr Sender: "TECO DRYER" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Thu, 7 Aug 2008 00:12:23 +0300 Message-ID: <20080806211223463.59F33D6A56552EF2@erkan-e90bf8060> X-Priority: 3 (Normal) Importance: Normal Teco Industry is in the business of corn, wheat, paddy, and vegetable drying machines and the production and marketing of silo & steel construction. Related to the machines that our company produce; Teco Industry has the representatives in Bulgaria, Albania, Ukraine, Tatarstan, Kazakhstan, Russia, Angola and Indonesia. Our partners in these countries are accepted as the leaders in the steel industry. The quality of produced machines is approved by international standards. Teco is guaranteed by CE and ISO 9001-2000 certificates. Teco also contributes to the national economy by creating jobs in designing, project, production, import and export. Teco materializes R&D activities with its professional staff. Quality results are presented to the customers during the production, import and export. Our company takes the leadership of producing and marketing nationally and internationally. For Grain, Oily Seeds, and Pulses: Silos Corn and Soybean Drying Machines Handling Systems like Bucket Elevator, Chain Conveyor and Helix Prop Towers and Catwalks for Handling Systems Unloading Truck Lifts Industrial Foundations, Steel Construction With the expert staff; we take an important target like ‘’Customer Satisfaction and Service Quality’’ and perform service and counseling duties successfully. -------------------------------------------------------------------------------- Contact Us , Teco Dryer Company is ready for a long partnership with you. Sales Engineer Erkan AYMAN eayman@tecodryer.com From owner-freebsd-net@FreeBSD.ORG Thu Aug 7 17:24:44 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9ED8D1065683; Thu, 7 Aug 2008 17:24:44 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 73CE48FC1B; Thu, 7 Aug 2008 17:24:44 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m77HOibF017622; Thu, 7 Aug 2008 17:24:44 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m77HOip5017618; Thu, 7 Aug 2008 17:24:44 GMT (envelope-from linimon) Date: Thu, 7 Aug 2008 17:24:44 GMT Message-Id: <200808071724.m77HOip5017618@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/126339: [ipw] ipw driver drops the connection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2008 17:24:44 -0000 Old Synopsis: ipw driver drops the connection New Synopsis: [ipw] ipw driver drops the connection Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Aug 7 17:24:05 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=126339 From owner-freebsd-net@FreeBSD.ORG Thu Aug 7 23:42:33 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 967091065678 for ; Thu, 7 Aug 2008 23:42:33 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 62EA68FC18 for ; Thu, 7 Aug 2008 23:42:33 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (HPooka@thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.3/8.14.3) with ESMTP id m77NDrXU021706 for ; Thu, 7 Aug 2008 18:13:53 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Thu, 7 Aug 2008 18:13:53 -0500 (CDT) From: "Sean C. Farley" To: freebsd-net@FreeBSD.org Message-ID: User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Spam-Status: No, score=-4.4 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail.farley.org Cc: Subject: Problems with first device on bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2008 23:42:33 -0000 On a 7-STABLE (built August 7th), I have noticed messages appearing in /var/log/messages: Aug 7 15:07:17 thor kernel: rtfree: 0xc7143a2c has 2 refs Aug 7 15:07:19 thor last message repeated 2 times Aug 7 15:09:28 thor last message repeated 3 times Aug 7 15:11:54 thor last message repeated 9 times This happens if I set up a bridge to have em0 and tap0 such as from: ifconfig bridge0 create ifconfig bridge0 addm em0 ifconfig bridge0 addm tap0 When I start QEMU on tap0, I would immediately lose IPv6 on em0 and eventually IPv4 would go away. I would get a lot more of messages about rtfree with QEMU started. >From experimentation (and some luck), I found that if I reversed the devices on a newly created bridge then the rtfree messages would go away, but I would have problems with tap0. The workaround: create two tap devices tap0 and tap1 and add to bridge0 in the order of tap1, tap0 and em0. On another system, I noticed that a bridge between real NIC's (em1 and sk0) also reports an rtfree message during boot. Any ideas? Sean -- scf@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Fri Aug 8 01:37:11 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F5EB106564A for ; Fri, 8 Aug 2008 01:37:11 +0000 (UTC) (envelope-from mo0118@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 583938FC1E for ; Fri, 8 Aug 2008 01:37:11 +0000 (UTC) (envelope-from mo0118@gmail.com) Received: by an-out-0708.google.com with SMTP id b33so152701ana.13 for ; Thu, 07 Aug 2008 18:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=+NBcSX4VrUUaSq1vJsmsovSNVeiK1/Li2l6wcTU6zY8=; b=vM8M1hOkAVsomcK/K/h60tBmXjinTzfJaNzcWr6moE6a2aFfaC+zhjwiqLn5a0v8ub 8QgUOUpO3Lu6wTdl5yWdAC8sDKZsxf/gFhUq/kpY8R7DG8NwgDispSurlmGtPDB4Ujd+ LX8zLWVnJcCEt9tpNNxS8ogiVHZcVMvwRyPyQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=p+LQbDQgFrFiJXDKLQ/eH9/lRLvbSGznWRja2udZvpqTj2rQzaHFnrMjbRzIQz6p3N lt8tZ4fJL1TM6nXGv3gqo5sphetPpxnk4pYDE66hYlzx9mY8uTwiWnBOeSmGgSjKDa5R ph/Uvetwwl4LW+LDVHB9JOeBor/sKmaXCTvVc= Received: by 10.100.142.4 with SMTP id p4mr3125290and.23.1218157901154; Thu, 07 Aug 2008 18:11:41 -0700 (PDT) Received: by 10.100.191.17 with HTTP; Thu, 7 Aug 2008 18:11:41 -0700 (PDT) Message-ID: Date: Fri, 8 Aug 2008 01:11:41 +0000 From: "Jeff Mo" To: damien.saucez@uclouvain.be, freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Question about "kern/125239: [gre] kernel crash when using gre" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2008 01:37:11 -0000 Hi Sir, I am trying to dive deeper into the stack frames of the following bug: kern/125239: [gre] kernel crash when using greI use FreeBSD 7.0 and already reproduce it, but I am not sure about what the following sentence means: "ifp=Variable "ifp" is not available"? I will be very thankful if anyone can give me some instruction. Regards Jeff ================== (kgdb) f 7 #7 0xc082263b in in_ifinit (ccc. ) at /usr/src/sys/netinet/in.c:817 817 if (rtinitflags(ia)) { (kgdb) info f Stack level 7, frame at 0xd22f3b58: eip = 0xc082263b in in_ifinit (/usr/src/sys/netinet/in.c:817); saved eip 0xc0823607 called by frame at 0xd22f3bb8, caller of frame at 0xd22f3ad4 source language c. Arglist at 0xd22f3b50, args: ifp=Variable "ifp" is not available. From owner-freebsd-net@FreeBSD.ORG Fri Aug 8 02:32:29 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C035106566B for ; Fri, 8 Aug 2008 02:32:29 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outD.internet-mail-service.net (outd.internet-mail-service.net [216.240.47.227]) by mx1.freebsd.org (Postfix) with ESMTP id 851628FC14 for ; Fri, 8 Aug 2008 02:32:29 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 62C3D2488; Thu, 7 Aug 2008 19:32:40 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id CE7D52D607E; Thu, 7 Aug 2008 19:32:28 -0700 (PDT) Message-ID: <489BB03C.4080803@elischer.org> Date: Thu, 07 Aug 2008 19:32:28 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Jeff Mo References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, damien.saucez@uclouvain.be Subject: Re: Question about "kern/125239: [gre] kernel crash when using gre" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2008 02:32:29 -0000 Jeff Mo wrote: > Hi Sir, > > I am trying to dive deeper into the stack frames of the following bug: > kern/125239: [gre] kernel crash when using greI use FreeBSD 7.0 and already > reproduce it, but I am not sure about what the following sentence means: > "ifp=Variable "ifp" is not available"? > > I will be very thankful if anyone can give me some instruction. > > Regards > Jeff > > ================== > > (kgdb) f 7 > #7 0xc082263b in in_ifinit (ccc. > ) at /usr/src/sys/netinet/in.c:817 > 817 if (rtinitflags(ia)) { > (kgdb) info f > Stack level 7, frame at 0xd22f3b58: > eip = 0xc082263b in in_ifinit (/usr/src/sys/netinet/in.c:817); > saved eip 0xc0823607 > called by frame at 0xd22f3bb8, caller of frame at 0xd22f3ad4 > source language c. > Arglist at 0xd22f3b50, args: ifp=Variable "ifp" is not available. ifp was in a register and is no longer valid at this point. > _______________________________________________ > 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 Aug 8 06:04:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 546431065676 for ; Fri, 8 Aug 2008 06:04:57 +0000 (UTC) (envelope-from Younger.Wang@packetfront.com) Received: from mail.packetfront.com (mail.packetfront.com [212.247.6.198]) by mx1.freebsd.org (Postfix) with ESMTP id C31928FC13 for ; Fri, 8 Aug 2008 06:04:56 +0000 (UTC) (envelope-from Younger.Wang@packetfront.com) Received: from localhost (localhost [127.0.0.1]) by mail.packetfront.com (Postfix) with ESMTP id E85C2A30C1 for ; Fri, 8 Aug 2008 07:37:02 +0200 (CEST) Received: from mail.packetfront.com ([127.0.0.1]) by localhost (mail.packetfront.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32672-07 for ; Fri, 8 Aug 2008 07:37:02 +0200 (CEST) Received: from fw.packetfront.com (unknown [192.121.165.1]) by mail.packetfront.com (Postfix) with ESMTP id A671BA30A4 for ; Fri, 8 Aug 2008 07:37:02 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Aug 2008 07:39:20 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (Netgraph problem) Inner tag and outer tag swapped Thread-Index: Acj5GRsFFO28nHmETJCJcoGu7FyVSA== From: "Younger Wang" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at packetfront.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: (Netgraph problem) Inner tag and outer tag swapped X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2008 06:04:57 -0000 Hi, =20 fxp0 is connected to a trunk port. Frames tagged with VID=3D201 arrives = at fxp0 from a switch trunk port, I expect it will be captured at hub_QinQ, with outer tag =3D 4000, and inner tag =3D 201. But in fact, it was = received with the outer and inner tags reversed. =20 But if I inject the same frame on hub_c4000, the frame is received at hub_QinQ as expected (inner tag =3D 201, outer tag =3D 4000). I am = really confused. Has anyone seen the same problem? Big thanks. =20 Here is my netgraph setup: =20 ngctl mkpeer fxp0: hub lower physical ngctl name fxp0:lower hub_c4000 =20 ngctl mkpeer hub_c4000: vlan up vlan4000 ngctl name hub_c4000:up vlan_QinQ =20 ngctl mkpeer vlan_QinQ: hub downstream down0 ngctl name vlan_QinQ:downstream hub_QinQ =20 ngctl msg vlan_QinQ: addfilter { vlan=3D4000 hook=3D"vlan4000" } =20 BR Younger Wang =20 =20 From owner-freebsd-net@FreeBSD.ORG Fri Aug 8 12:49:16 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 147D41065674 for ; Fri, 8 Aug 2008 12:49:16 +0000 (UTC) (envelope-from rfrench@freebsd.org) Received: from oberon.wxnz.net (oberon.wxnz.net [58.28.6.13]) by mx1.freebsd.org (Postfix) with ESMTP id CCDAF8FC2C for ; Fri, 8 Aug 2008 12:49:15 +0000 (UTC) (envelope-from rfrench@freebsd.org) Received: from mini-tank.local (ip-58-28-152-154.static-xdsl.xnet.co.nz [58.28.152.154]) by oberon.wxnz.net (Postfix) with ESMTP id 981BF464515 for ; Sat, 9 Aug 2008 00:35:57 +1200 (NZST) From: Ryan French To: freebsd-net@freebsd.org Date: Sat, 9 Aug 2008 00:32:53 +1200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808090032.53611.rfrench@freebsd.org> Subject: Probem with protosw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2008 12:49:16 -0000 Hi, I am working on my implementation of MPLS in FreeBSD and I'm having problems with integrating the code I have ported over into the FreeBSD networking stack. The problem I am having at the moment is trying to get my mpls protocol struct to compile. When I try to build the kernel I get a pr_* undeclared here (not in a function) error, for each field of the struct I have declared. I have included the code just in case anyone is able to figure this out. Thanks, Ryan French #include #include #include #include #include #include #include #include #include #include #include #include /* * MPLS protocol family: */ extern struct domain mplsdomain; struct protosw mplssw[] = { { pr_type = 0, pr_domain = &mplsdomain, pr_init = mpls_init, pr_sysctl = mpls_sysctl }, { pr_type = SOCK_DGRAM, pr_domain = &mplsdomain, pr_flags = PR_ATOMIC | PR_ADDR, pr_usrreq = mpls_raw_usrreq, pr_sysctl = mpls_sysctl }, /* raw wildcard */ { pr_type = SOCK_RAW, pr_domain = &mplsdomain, pr_flags = PR_ATOMIC | PR_ADDR, pr_usrreq = mpls_raw_usrreq, pr_sysctl = mpls_sysctl }, }; struct domain mplsdomain = { NETISR_MPLS, "mpls", mpls_init, 0, 0, mplssw, &mplssw[sizeof(mplssw)/sizeof(mplssw[0])], 0, rn_inithead, offsetof(struct sockaddr_mpls, smpls_in_ifindex) << 3, sizeof(struct sockaddr_mpls) }; From owner-freebsd-net@FreeBSD.ORG Fri Aug 8 13:12:04 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71C391065671; Fri, 8 Aug 2008 13:12:04 +0000 (UTC) (envelope-from gonzo@freebsd.org) Received: from luidgi.portaone.com (luidgi.portaone.com [195.138.219.143]) by mx1.freebsd.org (Postfix) with ESMTP id 53AA98FC19; Fri, 8 Aug 2008 13:12:04 +0000 (UTC) (envelope-from gonzo@freebsd.org) Received: from mail.pbxpress.com ([65.61.203.142] helo=leaf.pbxpress.com) by luidgi.portaone.com (8.11.3/8.11.3) with ESMTP (TLSv1:AES256-SHA:256)id 1KRRY9-000KKh-VD; Fri, 08 Aug 2008 05:58:33 -0700 Received: from jeeves.bluezbox.com (k3-gw.portaone.com [193.28.87.193]) (authenticated bits=0) by leaf.pbxpress.com (8.13.3/8.13.3) with ESMTP id m78D1ivL047153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2008 06:01:47 -0700 (PDT) (envelope-from gonzo@freebsd.org) Message-ID: <489C42F9.1030207@freebsd.org> Date: Fri, 08 Aug 2008 15:58:33 +0300 From: Oleksandr Tymoshenko User-Agent: Thunderbird 2.0.0.14 (X11/20080704) MIME-Version: 1.0 To: Ryan French References: <200808090032.53611.rfrench@freebsd.org> In-Reply-To: <200808090032.53611.rfrench@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, recieved from trusted server Cc: freebsd-net@freebsd.org Subject: Re: Probem with protosw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2008 13:12:04 -0000 Ryan French wrote: > Hi, > > I am working on my implementation of MPLS in FreeBSD and I'm having problems > with integrating the code I have ported over into the FreeBSD networking > stack. The problem I am having at the moment is trying to get my mpls > protocol struct to compile. When I try to build the kernel I get a pr_* > undeclared here (not in a function) error, for each field of the struct I > have declared. I have included the code just in case anyone is able to figure > this out. Syntax is wrong, there are no dots before pr_. Code should look like: struct protosw mplssw[] = { { .pr_type = 0, .pr_domain = &mplsdomain, .pr_init = mpls_init, .pr_sysctl = mpls_sysctl }, { -- gonzo From owner-freebsd-net@FreeBSD.ORG Fri Aug 8 16:27:19 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB2371065671 for ; Fri, 8 Aug 2008 16:27:19 +0000 (UTC) (envelope-from Younger.Wang@packetfront.com) Received: from mail.packetfront.com (mail.packetfront.com [212.247.6.198]) by mx1.freebsd.org (Postfix) with ESMTP id 4960B8FC0A for ; Fri, 8 Aug 2008 16:27:18 +0000 (UTC) (envelope-from Younger.Wang@packetfront.com) Received: from localhost (localhost [127.0.0.1]) by mail.packetfront.com (Postfix) with ESMTP id 0B166A30DF; Fri, 8 Aug 2008 18:26:50 +0200 (CEST) Received: from mail.packetfront.com ([127.0.0.1]) by localhost (mail.packetfront.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25962-01; Fri, 8 Aug 2008 18:26:49 +0200 (CEST) Received: from fw.packetfront.com (unknown [192.121.165.1]) by mail.packetfront.com (Postfix) with ESMTP id B48B8A30D8; Fri, 8 Aug 2008 18:26:49 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Aug 2008 18:29:08 +0200 Message-ID: In-Reply-To: <489C0DDA.8040606@elischer.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (Netgraph problem) Inner tag and outer tag swapped Thread-Index: Acj5aYOBdRkAhUCDQxS+dRRAHdC5lQACSVHA References: <489C0DDA.8040606@elischer.org> From: "Younger Wang" To: "Julian Elischer" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at packetfront.com Cc: freebsd-net@freebsd.org Subject: RE: (Netgraph problem) Inner tag and outer tag swapped X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2008 16:27:19 -0000 Hi, I expect to see [Ether header][tag 4000][tag 201][payload] in hub_QinQ, but in fact it was [ether header][tag 201][tag 4000][payload]. I inserted the hub because I wanted to sniffer in the segment. It should not cause any problem, should it? The system I run is based on vimage_7-20080228.tgz (http://imunes.tel.fer.hr/virtnet/), on FreeBSD Release 7, with ng_vlan module modified to support changing ethertype. My modification was made for release 7 however. Yes, the difference between vimage source and release 7 could be the cause. I will check it during the weekend.=20 Big thanks! BR Younger Wang -----Original Message----- From: Julian Elischer [mailto:julian@elischer.org]=20 Sent: Friday, August 08, 2008 5:12 PM To: Younger Wang Subject: Re: (Netgraph problem) Inner tag and outer tag swapped Younger Wang wrote: > Hi, >=20 > =20 >=20 > fxp0 is connected to a trunk port. Frames tagged with VID=3D201 = arrives at > fxp0 from a switch trunk port, I expect it will be captured at hub_QinQ, > with outer tag =3D 4000, and inner tag =3D 201. But in fact, it was received > with the outer and inner tags reversed. is this what you think is on the wire? [ether header][tag 201][tag 4000][payload] >=20 > =20 >=20 > But if I inject the same frame on hub_c4000, the frame is received at > hub_QinQ as expected (inner tag =3D 201, outer tag =3D 4000). I am = really > confused. Has anyone seen the same problem? Big thanks. >=20 > =20 >=20 > Here is my netgraph setup: >=20 > =20 >=20 > ngctl mkpeer fxp0: hub lower physical >=20 > ngctl name fxp0:lower hub_c4000 looking at your config.. I see: [hub] down0 | downstream [vlan] vlan4000 | up [hub] <--- why do you need this? physical | lower [ether] what version of FreeBSD? some changes were made in vlan handling in the late6/7 timeframe. >=20 > =20 >=20 > ngctl mkpeer hub_c4000: vlan up vlan4000 >=20 > ngctl name hub_c4000:up vlan_QinQ >=20 > =20 >=20 > ngctl mkpeer vlan_QinQ: hub downstream down0 >=20 > ngctl name vlan_QinQ:downstream hub_QinQ >=20 > =20 >=20 > ngctl msg vlan_QinQ: addfilter { vlan=3D4000 hook=3D"vlan4000" } >=20 > =20 >=20 > BR >=20 > Younger Wang >=20 > =20 >=20 > =20 >=20 > _______________________________________________ > 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 Aug 8 16:36:51 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE34B106567A for ; Fri, 8 Aug 2008 16:36:51 +0000 (UTC) (envelope-from Younger.Wang@packetfront.com) Received: from mail.packetfront.com (mail.packetfront.com [212.247.6.198]) by mx1.freebsd.org (Postfix) with ESMTP id 364FB8FC20 for ; Fri, 8 Aug 2008 16:36:50 +0000 (UTC) (envelope-from Younger.Wang@packetfront.com) Received: from localhost (localhost [127.0.0.1]) by mail.packetfront.com (Postfix) with ESMTP id 34D69A30DF; Fri, 8 Aug 2008 18:36:22 +0200 (CEST) Received: from mail.packetfront.com ([127.0.0.1]) by localhost (mail.packetfront.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25163-10; Fri, 8 Aug 2008 18:36:21 +0200 (CEST) Received: from fw.packetfront.com (unknown [192.121.165.1]) by mail.packetfront.com (Postfix) with ESMTP id D2402A30D8; Fri, 8 Aug 2008 18:36:21 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Aug 2008 18:38:46 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (Netgraph problem) Inner tag and outer tag swapped Thread-Index: Acj5aYOBdRkAhUCDQxS+dRRAHdC5lQACSVHAAACQBqA= References: <489C0DDA.8040606@elischer.org> From: "Younger Wang" To: "Younger Wang" , "Julian Elischer" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at packetfront.com Cc: freebsd-net@freebsd.org Subject: RE: (Netgraph problem) Inner tag and outer tag swapped X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2008 16:36:51 -0000 I diffed ng_vlan source between release 7 and vimage_7-20080228. They are identical. I will discard my own modification and try original vimage_7-20080228; if it does not still work, I will roll back to release 7 kernel and try again. Thank you so much for the hints. BR Younger Wang -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Younger Wang Sent: Saturday, August 09, 2008 12:29 AM To: Julian Elischer Cc: freebsd-net@freebsd.org Subject: RE: (Netgraph problem) Inner tag and outer tag swapped Hi, I expect to see [Ether header][tag 4000][tag 201][payload] in hub_QinQ, but in fact it was [ether header][tag 201][tag 4000][payload]. I inserted the hub because I wanted to sniffer in the segment. It should not cause any problem, should it? The system I run is based on vimage_7-20080228.tgz (http://imunes.tel.fer.hr/virtnet/), on FreeBSD Release 7, with ng_vlan module modified to support changing ethertype. My modification was made for release 7 however. Yes, the difference between vimage source and release 7 could be the cause. I will check it during the weekend.=20 Big thanks! BR Younger Wang -----Original Message----- From: Julian Elischer [mailto:julian@elischer.org]=20 Sent: Friday, August 08, 2008 5:12 PM To: Younger Wang Subject: Re: (Netgraph problem) Inner tag and outer tag swapped Younger Wang wrote: > Hi, >=20 > =20 >=20 > fxp0 is connected to a trunk port. Frames tagged with VID=3D201 = arrives at > fxp0 from a switch trunk port, I expect it will be captured at hub_QinQ, > with outer tag =3D 4000, and inner tag =3D 201. But in fact, it was received > with the outer and inner tags reversed. is this what you think is on the wire? [ether header][tag 201][tag 4000][payload] >=20 > =20 >=20 > But if I inject the same frame on hub_c4000, the frame is received at > hub_QinQ as expected (inner tag =3D 201, outer tag =3D 4000). I am = really > confused. Has anyone seen the same problem? Big thanks. >=20 > =20 >=20 > Here is my netgraph setup: >=20 > =20 >=20 > ngctl mkpeer fxp0: hub lower physical >=20 > ngctl name fxp0:lower hub_c4000 looking at your config.. I see: [hub] down0 | downstream [vlan] vlan4000 | up [hub] <--- why do you need this? physical | lower [ether] what version of FreeBSD? some changes were made in vlan handling in the late6/7 timeframe. >=20 > =20 >=20 > ngctl mkpeer hub_c4000: vlan up vlan4000 >=20 > ngctl name hub_c4000:up vlan_QinQ >=20 > =20 >=20 > ngctl mkpeer vlan_QinQ: hub downstream down0 >=20 > ngctl name vlan_QinQ:downstream hub_QinQ >=20 > =20 >=20 > ngctl msg vlan_QinQ: addfilter { vlan=3D4000 hook=3D"vlan4000" } >=20 > =20 >=20 > BR >=20 > Younger Wang >=20 > =20 >=20 > =20 >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Aug 8 16:58:58 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2229106567C for ; Fri, 8 Aug 2008 16:58:58 +0000 (UTC) (envelope-from Younger.Wang@packetfront.com) Received: from mail.packetfront.com (mail.packetfront.com [212.247.6.198]) by mx1.freebsd.org (Postfix) with ESMTP id 7B9808FC13 for ; Fri, 8 Aug 2008 16:58:58 +0000 (UTC) (envelope-from Younger.Wang@packetfront.com) Received: from localhost (localhost [127.0.0.1]) by mail.packetfront.com (Postfix) with ESMTP id 50644A30D8; Fri, 8 Aug 2008 18:58:29 +0200 (CEST) Received: from mail.packetfront.com ([127.0.0.1]) by localhost (mail.packetfront.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28908-02; Fri, 8 Aug 2008 18:58:28 +0200 (CEST) Received: from fw.packetfront.com (unknown [192.121.165.1]) by mail.packetfront.com (Postfix) with ESMTP id EBDB8A30D3; Fri, 8 Aug 2008 18:58:28 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Aug 2008 19:00:43 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (Netgraph problem) Inner tag and outer tag swapped Thread-Index: Acj5aYOBdRkAhUCDQxS+dRRAHdC5lQACSVHAAAFI5MA= References: <489C0DDA.8040606@elischer.org> From: "Younger Wang" To: "Younger Wang" , "Julian Elischer" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at packetfront.com Cc: freebsd-net@freebsd.org Subject: RE: (Netgraph problem) Inner tag and outer tag swapped X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2008 16:58:59 -0000 I have rolled back to release 7 kernel. The problem is still there.=20 The problem is seen only when the single tagged frame ingresses from an ether node. I tested it on bge and fxp cards. If the single tagged frame was injected from an eiface interface, there is no problem.=20 BR Younger Wang -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Younger Wang Sent: Saturday, August 09, 2008 12:29 AM To: Julian Elischer Cc: freebsd-net@freebsd.org Subject: RE: (Netgraph problem) Inner tag and outer tag swapped Hi, I expect to see [Ether header][tag 4000][tag 201][payload] in hub_QinQ, but in fact it was [ether header][tag 201][tag 4000][payload]. I inserted the hub because I wanted to sniffer in the segment. It should not cause any problem, should it? The system I run is based on vimage_7-20080228.tgz (http://imunes.tel.fer.hr/virtnet/), on FreeBSD Release 7, with ng_vlan module modified to support changing ethertype. My modification was made for release 7 however. Yes, the difference between vimage source and release 7 could be the cause. I will check it during the weekend.=20 Big thanks! BR Younger Wang -----Original Message----- From: Julian Elischer [mailto:julian@elischer.org]=20 Sent: Friday, August 08, 2008 5:12 PM To: Younger Wang Subject: Re: (Netgraph problem) Inner tag and outer tag swapped Younger Wang wrote: > Hi, >=20 > =20 >=20 > fxp0 is connected to a trunk port. Frames tagged with VID=3D201 = arrives at > fxp0 from a switch trunk port, I expect it will be captured at hub_QinQ, > with outer tag =3D 4000, and inner tag =3D 201. But in fact, it was received > with the outer and inner tags reversed. is this what you think is on the wire? [ether header][tag 201][tag 4000][payload] >=20 > =20 >=20 > But if I inject the same frame on hub_c4000, the frame is received at > hub_QinQ as expected (inner tag =3D 201, outer tag =3D 4000). I am = really > confused. Has anyone seen the same problem? Big thanks. >=20 > =20 >=20 > Here is my netgraph setup: >=20 > =20 >=20 > ngctl mkpeer fxp0: hub lower physical >=20 > ngctl name fxp0:lower hub_c4000 looking at your config.. I see: [hub] down0 | downstream [vlan] vlan4000 | up [hub] <--- why do you need this? physical | lower [ether] what version of FreeBSD? some changes were made in vlan handling in the late6/7 timeframe. >=20 > =20 >=20 > ngctl mkpeer hub_c4000: vlan up vlan4000 >=20 > ngctl name hub_c4000:up vlan_QinQ >=20 > =20 >=20 > ngctl mkpeer vlan_QinQ: hub downstream down0 >=20 > ngctl name vlan_QinQ:downstream hub_QinQ >=20 > =20 >=20 > ngctl msg vlan_QinQ: addfilter { vlan=3D4000 hook=3D"vlan4000" } >=20 > =20 >=20 > BR >=20 > Younger Wang >=20 > =20 >=20 > =20 >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Aug 8 21:23:44 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A27961065674 for ; Fri, 8 Aug 2008 21:23:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outA.internet-mail-service.net (outa.internet-mail-service.net [216.240.47.224]) by mx1.freebsd.org (Postfix) with ESMTP id 875138FC1A for ; Fri, 8 Aug 2008 21:23:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 9AFED2517; Fri, 8 Aug 2008 14:23:44 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id BABA52D6097; Fri, 8 Aug 2008 14:23:43 -0700 (PDT) Message-ID: <489CB95E.5090202@elischer.org> Date: Fri, 08 Aug 2008 14:23:42 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Younger Wang References: <489C0DDA.8040606@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: (Netgraph problem) Inner tag and outer tag swapped X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2008 21:23:44 -0000 Younger Wang wrote: > Hi, > > I expect to see [Ether header][tag 4000][tag 201][payload] in hub_QinQ, > but in fact it was [ether header][tag 201][tag 4000][payload]. > > I inserted the hub because I wanted to sniffer in the segment. It should > not cause any problem, should it? probably not.. that is what the 'tee' node is for though. > > The system I run is based on vimage_7-20080228.tgz > (http://imunes.tel.fer.hr/virtnet/), on FreeBSD Release 7, with ng_vlan > module modified to support changing ethertype. My modification was made > for release 7 however. Yes, the difference between vimage source and > release 7 could be the cause. I will check it during the weekend. ok that shouldn't make a difference.. on thing is that the vlan header is removed very early (just before the packet is handed to netgraph) and replaced by a packet tag (metadata) is is added back on (at the front) before transmission so that may be related how the headers swap position. it is possible that the vlan node converts the tag back to a header. I'm not sure exactly where it gets added back but it may be worth looking to see if the vlan type does so... > > Big thanks! > > BR > Younger Wang > > -----Original Message----- > From: Julian Elischer [mailto:julian@elischer.org] > Sent: Friday, August 08, 2008 5:12 PM > To: Younger Wang > Subject: Re: (Netgraph problem) Inner tag and outer tag swapped > > Younger Wang wrote: >> Hi, >> >> >> >> fxp0 is connected to a trunk port. Frames tagged with VID=201 arrives > at >> fxp0 from a switch trunk port, I expect it will be captured at > hub_QinQ, >> with outer tag = 4000, and inner tag = 201. But in fact, it was > received >> with the outer and inner tags reversed. > > is this what you think is on the wire? > > > [ether header][tag 201][tag 4000][payload] > >> >> >> But if I inject the same frame on hub_c4000, the frame is received at >> hub_QinQ as expected (inner tag = 201, outer tag = 4000). I am really >> confused. Has anyone seen the same problem? Big thanks. >> >> >> >> Here is my netgraph setup: >> >> >> >> ngctl mkpeer fxp0: hub lower physical >> >> ngctl name fxp0:lower hub_c4000 > > looking at your config.. I see: > > > [hub] > down0 > | > downstream > [vlan] > vlan4000 > | > up > [hub] <--- why do you need this? > physical > | > lower > [ether] > > > what version of FreeBSD? > some changes were made in vlan handling in the late6/7 timeframe. > > >> >> >> ngctl mkpeer hub_c4000: vlan up vlan4000 >> >> ngctl name hub_c4000:up vlan_QinQ >> >> >> >> ngctl mkpeer vlan_QinQ: hub downstream down0 >> >> ngctl name vlan_QinQ:downstream hub_QinQ >> >> >> >> ngctl msg vlan_QinQ: addfilter { vlan=4000 hook="vlan4000" } >> >> >> >> BR >> >> Younger Wang >> >> >> >> >> >> _______________________________________________ >> 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 Aug 8 23:26:34 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EEEF1065671 for ; Fri, 8 Aug 2008 23:26:34 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by mx1.freebsd.org (Postfix) with ESMTP id F11278FC0C for ; Fri, 8 Aug 2008 23:26:33 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1818046rvf.43 for ; Fri, 08 Aug 2008 16:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=EUHjnYYAZ6DXf0Ao53UvHDmpW3VQgQPhkfRXYe7n6sM=; b=Ugm2KqB0PVxSP4+4WFhQhBUjB1zzXRk09OhjLvmVob3hkfE2FmmSxJe//I/JXA4/Hn 8vs1A11CDF9E1GoIwxvkuwwVw3O4BpWt3mbz4DtSMYv+kIuxnuNHhyNBhk0ILvHLWhz7 63lEKe6AYZxwuVK7HvfKte9Mq6MIhtmZI+xOc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=DpuUPEvOmBbpMfIOhnicRU68JOOcB0u9s0mmpFlZIisno0L3o2mBZNg7ynw5Qv0+xt 68iyC53yi7ZU1tqKxC8HPPnT9WEl9pf0yVNcBfUsm6qRzUEneXTHh2BL0rxAKX7p05AZ 9nTZlK62MYJ+hOB3CznT79J15Q20xJ3zHjHns= Received: by 10.141.170.10 with SMTP id x10mr1759577rvo.140.1218237993682; Fri, 08 Aug 2008 16:26:33 -0700 (PDT) Received: by 10.141.176.12 with HTTP; Fri, 8 Aug 2008 16:26:33 -0700 (PDT) Message-ID: <9a542da30808081626y7ce1fe58k483494a6cdbfae60@mail.gmail.com> Date: Sat, 9 Aug 2008 01:26:33 +0200 From: "=?ISO-8859-1?Q?Ermal_Lu=E7i?=" To: "Mike Makonnen" In-Reply-To: <48945A79.50300@wubethiopia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> <48922E9D.1020507@elischer.org> <4893328C.2040105@freebsdbrasil.com.br> <4894447C.3000800@wubethiopia.com> <48945A79.50300@wubethiopia.com> Cc: freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2008 23:26:34 -0000 On Sat, Aug 2, 2008 at 3:00 PM, Mike Makonnen wrote: > Mike Makonnen wrote: >> >> Patrick Tracanelli wrote: >>> >>> To let you know of my current (real world) tests: >>> >>> - Wireless Internet Provider 1: >>> - 4Mbit/s of Internet Traffic >>> - Classifying default protocols + soulseek + ssh >>> - Classifying 100Mbit/s of dump over ssh >>> >>> Results in: >>> No latency added, very low CPU usage, no packets dropping. >>> >>> - Wireless ISP 2: >>> - 21 Mbit/s of Internet Traffic >>> - Classifying default protocols + soulseek + ssh >>> >>> Results in: >>> No tcp or udp traffic at all; everything that gets diverted never >>> comes out of the divert socket, and ipfw-classifyd logs >>> >>> Aug 1 12:07:35 ourofino last message repeated 58 times >>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: bittorrent >>> (rule 50000) >>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: edonkey (rule >>> 50000) >>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: fasttrack (rule >>> 50000) >>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: gnutella (rule >>> 1000) >>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: soulseek (rule >>> 50000) >>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: ssh (rule >>> 50000) >>> Aug 1 12:18:28 ourofino ipfw-classifyd: unable to write to divert >>> socket: Operation not permitted >>> Aug 1 12:18:50 ourofino last message repeated 90 times >> >> Hmmm... this part means that the call to sendto(2) to write the packet >> back into network stack failed. This explains why you are not seein g any >> traffic comming back out of the divert socket, but I don't see why it would >> suddenly fail with a permission error. Could this be a kernel bug? >>> >>> Aug 1 12:18:51 ourofino ipfw-classifyd: packet dropped: input queue full >>> Aug 1 12:19:11 ourofino last message repeated 94 times >>> >>> Raised queue len a lot (up to 40960), when the application starts it uses >>> up to 25% CPU and a second after that, CPU usage gets lower the 0.1%. >> >> This looks like a deadlock. If it weren't able to process packets fast >> enough the cpu usage should be high even as it's spewing "packet dropped" >> messages. Can you send me some more information like memory usage and the >> firewall script you are using? How much of the 21Mbits/s of traffic is P2P? >> If you reduce the number of protocols you are trying to match against does >> the behavior change? Using netstat -w1 -I can you tell me how >> many packets per second we're talking about for 4Mbits/s and 21Mbit/s? Also, >> the timestamps from the log file seem to show that the daemon is running for >> approx. 34 sec. before the first "unable to write to write to divert socket" >> message. Is it passing traffic during this time? Thanks. >> >> I've uploaded a newer version. Can you try that also please. It includes: >> o SIGHUP forces it to re-read its configuration file >> o rc.d script >> o minor optimization (calls pthread_cond_signal with the mutex unlocked) >> o code cleanup >> >> Also, for your convenience I have attached a patch against the earlier >> version that removes a debugging printf that should remove spammage to your >> log files (the current version has it removed already). >> > > Ooops, a few minutes after I sent this email I found a couple of bugs (one > major, and one minor). They were in the original tarball as well as the > newer one I uploaded earlier today. I've uploaded a fixed version of the > code. Can you try that instead please. > > Also, to help track down performance issues I've modified the Makefile to > build a profiled version of the application so you can use gprof(1) to > figure out where any problems lie. > Does this sound about right for implementing the GC and implementing syntax as $protocol = dnpipe 20 $protocol2 = dnqueue 30 it has some extra goos for pf(4) and altq(4) $protocol3 = queue $queue name $protocol4 = tag TAGNAME $protocol5 = action block It adds 2 new options -e seconds for seconds before a flow is considered expired and -n #packets proccessed before kicking the GC. --- classifyd_old.c 2008-08-09 00:33:04.000000000 +0000 +++ classifyd.c 2008-08-09 00:33:34.000000000 +0000 @@ -28,13 +28,17 @@ #include #include +#include +#include +#include #include #include #include #include #include #include +#include #include #include @@ -53,6 +57,7 @@ #include #include "hashtable.h" +#include "hashtable_private.h" #include "pathnames.h" #include "protocols.h" @@ -94,6 +99,7 @@ uint32_t if_datalen; /* length in bytes of if_data */ uint16_t if_pktcount; /* number of packets concatenated */ uint16_t if_fwrule; /* ipfw(4) rule associated with flow */ + time_t expire; /* flow expire time */ }; /* @@ -126,7 +132,7 @@ static struct ic_queue outQ; /* divert(4) socket */ -static int dvtS; +static int dvtS = 0; /* config file path */ static const char *conf = IC_CONFIG_PATH; @@ -137,12 +143,25 @@ /* List of protocols available to the system */ struct ic_protocols *fp; +/* Our hashtables */ +struct hashtable *sh = NULL, + *th = NULL, + *uh = NULL; + +/* signaled to kick garbage collector */ +static pthread_cond_t gq_condvar; + +/* number of packets before kicking garbage collector */ +static unsigned int npackets = 250; + +static time_t time_expire = 40; /* 40 seconds */ /* * Forward function declarations. */ void *classify_pthread(void *); void *read_pthread(void *); void *write_pthread(void *); +void *garbage_pthread(void *); static int equalkeys(void *, void *); static unsigned int hashfromkey(void *); static void test_re(void); @@ -155,7 +174,7 @@ { struct sockaddr_in addr; struct sigaction sa; - pthread_t classifytd, readtd, writetd; + pthread_t classifytd, readtd, writetd, garbagectd; const char *errstr; long long num; uint16_t port, qmaxsz; @@ -164,13 +183,27 @@ tflag = 0; port = IC_DPORT; qmaxsz = IC_QMAXSZ; - while ((ch = getopt(argc, argv, "htc:P:p:q:")) != -1) { + while ((ch = getopt(argc, argv, "n:e:htc:P:p:q:")) != -1) { switch(ch) { case 'c': conf = strdup(optarg); if (conf == NULL) err(EX_TEMPFAIL, "config file path"); break; + case 'e': + num = strtonum((const char *)optarg, 1, 400, &errstr); + if (num == 0 && errstr != NULL) { + errx(EX_USAGE, "invalud expire seconds: %s", errstr); + } + time_expire = (time_t)num; + break; + case 'n': + num = strtonum((const char *)optarg, 1, 65535, &errstr); + if (num == 0 && errstr != NULL) { + errx(EX_USAGE, "invalud expire seconds: %s", errstr); + } + npackets = (unsigned int)num; + break; case 'P': protoDir = strdup(optarg); if (protoDir == NULL) @@ -230,6 +263,9 @@ error = pthread_cond_init(&outQ.fq_condvar, NULL); if (error != 0) err(EX_OSERR, "unable to initialize output queue condvar"); + error = pthread_cond_init(&gq_condvar, NULL); + if (error != 0) + err(EX_OSERR, "unable to initialize garbage collector condvar"); /* * Create and bind the divert(4) socket. @@ -276,32 +312,80 @@ if (error == -1) err(EX_OSERR, "unable to set signal handler"); + /* + * There are 3 tables: udp, tcp, and tcp syn. + * The tcp syn table tracks connections for which a + * SYN packet has been sent but no reply has been returned + * yet. Once the SYN ACK reply is detected it is moved to + * the regular tcp connection tracking table. + */ + sh = create_hashtable(IC_HASHSZ, hashfromkey, equalkeys); + if (sh == NULL) { + syslog(LOG_ERR, "unable to create TCP (SYN) tracking table"); + error = EX_SOFTWARE; + goto cleanup; + } + th = create_hashtable(IC_HASHSZ, hashfromkey, equalkeys); + if (th == NULL) { + syslog(LOG_ERR, "unable to create TCP tracking table"); + error = EX_SOFTWARE; + goto cleanup; + } + uh = create_hashtable(IC_HASHSZ, hashfromkey, equalkeys); + if (uh == NULL) { + syslog(LOG_ERR, "unable to create UDP tracking table"); + error = EX_SOFTWARE; + goto cleanup; + } + /* * Create the various threads. */ error = pthread_create(&readtd, NULL, read_pthread, NULL); - if (error != 0) - err(EX_OSERR, "unable to create reader thread"); + if (error != 0) { + syslog(LOG_ERR, "unable to create reader thread"); + error = EX_OSERR; + goto cleanup; + } error = pthread_create(&classifytd, NULL, classify_pthread, NULL); - if (error != 0) - err(EX_OSERR, "unable to create classifier thread"); + if (error != 0) { + syslog(LOG_ERR, "unable to create classifier thread"); + error = EX_OSERR; + goto cleanup; + } error = pthread_create(&writetd, NULL, write_pthread, NULL); - if (error != 0) - err(EX_OSERR, "unable to create writer thread"); - + if (error != 0) { + syslog(LOG_ERR, "unable to create writer thread"); + error = EX_OSERR; + goto cleanup; + } + error = pthread_create(&garbagectd, NULL, garbage_pthread, NULL); + if (error != 0) { + syslog(LOG_ERR, "unable to create garbage collect thread"); + error = EX_OSERR; + goto cleanup; + } /* * Wait for our threads to exit. */ pthread_join(readtd, NULL); pthread_join(classifytd, NULL); pthread_join(writetd, NULL); - + pthread_join(garbagectd, NULL); /* * Cleanup */ - close(dvtS); +cleanup: + if (dvtS > 0) + close(dvtS); + if (sh != NULL) + hashtable_destroy(sh, 1); + if (th != NULL) + hashtable_destroy(th, 1); + if (uh != NULL) + hashtable_destroy(uh, 1); - return (0); + return (error); } void * @@ -310,6 +394,7 @@ struct ic_pkt *pkt; struct ip *ipp; int len; + unsigned int pcktcnt = 0; while (1) { pkt = (struct ic_pkt *)malloc(sizeof(struct ic_pkt)); @@ -353,6 +438,10 @@ STAILQ_INSERT_HEAD(&inQ.fq_pkthead, pkt, fp_link); inQ.fq_size++; pthread_mutex_unlock(&inQ.fq_mtx); + if (++pcktcnt > npackets) { + pcktcnt = 0; + pthread_cond_signal(&gq_condvar); + } pthread_cond_signal(&inQ.fq_condvar); } @@ -420,39 +509,19 @@ struct tcphdr *tcp; struct udphdr *udp; struct ic_pkt *pkt; - struct hashtable *sh, *th, *uh; struct protocol *proto; + struct timeval tv; regmatch_t pmatch; u_char *data, *payload; uint16_t trycount; int datalen, error; - /* - * There are 3 tables: udp, tcp, and tcp syn. - * The tcp syn table tracks connections for which a - * SYN packet has been sent but no reply has been returned - * yet. Once the SYN ACK reply is detected it is moved to - * the regular tcp connection tracking table. - */ - sh = create_hashtable(IC_HASHSZ, hashfromkey, equalkeys); - if (sh == NULL) { - syslog(LOG_ERR, "unable to create TCP (SYN) tracking table"); - exit(EX_SOFTWARE); - } - th = create_hashtable(IC_HASHSZ, hashfromkey, equalkeys); - if (th == NULL) { - syslog(LOG_ERR, "unable to create TCP tracking table"); - exit(EX_SOFTWARE); - } - uh = create_hashtable(IC_HASHSZ, hashfromkey, equalkeys); - if (uh == NULL) { - syslog(LOG_ERR, "unable to create UDP tracking table"); - exit(EX_SOFTWARE); - } - flow = NULL; key = NULL; while(1) { + while(gettimeofday(&tv, NULL) != 0) + ; + pthread_mutex_lock(&inQ.fq_mtx); pkt = STAILQ_LAST(&inQ.fq_pkthead, ic_pkt, fp_link); while (pkt == NULL) { @@ -528,6 +597,8 @@ free(pkt); continue; } + + flow->expire = tv.tv_sec; goto enqueue; /* * Handle session tear-down. @@ -583,8 +654,11 @@ * collecting IC_PKTMAXMATCH packets, just pass it through. */ } else if (flow->if_pktcount >= IC_PKTMAXMATCH && - flow->if_fwrule == 0) + flow->if_fwrule == 0) { + flow->expire = tv.tv_sec; goto enqueue; + } + flow->expire = tv.tv_sec; goto classify; } @@ -630,6 +704,7 @@ free(pkt); continue; } + flow->expire = tv.tv_sec; goto classify; } @@ -688,6 +763,7 @@ flow->if_datalen = datalen; flow->if_pktcount = 1; flow->if_fwrule = 0; + flow->expire = tv.tv_sec; if (hashtable_insert(uh, (void *)key, (void *)flow) == 0) { syslog(LOG_WARNING, "packet dropped: unable to insert into table"); @@ -715,19 +791,26 @@ flow->if_data = data; flow->if_datalen += datalen; flow->if_pktcount++; + flow->expire = tv.tv_sec; /* * If we haven't been able to classify this flow after * collecting IC_PKTMAXMATCH packets, just pass it through. */ } else if (flow->if_pktcount >= IC_PKTMAXMATCH && - flow->if_fwrule == 0) + flow->if_fwrule == 0) { + flow->expire = tv.tv_sec; goto enqueue; + } } else /* Not an TCP or UDP packet. */ goto enqueue; classify: - assert(flow != NULL); + if (flow == NULL) { + syslog(LOG_ERR, "flow is null argghhhhhhh"); + goto enqueue; + } + //assert(flow != NULL); /* * Inform divert(4) what rule to send it to by @@ -823,6 +906,80 @@ return (NULL); } +void * +garbage_pthread(void *arg __unused) +{ + char errbuf[LINE_MAX]; + struct entry *e, *f; + unsigned int i, flows_expired, error; + struct timeval tv; + + while (1) { + flows_expired = 0; + while (gettimeofday(&tv, NULL) != 0) + ; + tv.tv_sec -= time_expire; + + pthread_mutex_lock(&inQ.fq_mtx); + error = pthread_cond_wait(&gq_condvar, &inQ.fq_mtx); + if (error != 0) { + strerror_r(error, errbuf, sizeof(errbuf)); + syslog(EX_OSERR, "unable to wait on garbage collection: %s", + errbuf); + exit(EX_OSERR); + } + + for (i = 0; i < sh->tablelength; i++) { + e = sh->table[i]; + while (e != NULL) { + f = e; e = e->next; + if (((struct ip_flow *)f->v)->expire < tv.tv_sec) { + freekey(f->k); + sh->entrycount--; + if (f->v != NULL) + free(f->v); + free(f); + flows_expired++; + } + } + } + for (i = 0; i < th->tablelength; i++) { + e = th->table[i]; + while (e != NULL) { + f = e; e = e->next; + if (((struct ip_flow *)f->v)->expire < tv.tv_sec) { + freekey(f->k); + th->entrycount--; + if (f->v != NULL) + free(f->v); + free(f); + flows_expired++; + } + } + } + for (i = 0; i < uh->tablelength; i++) { + e = uh->table[i]; + while (e != NULL) { + f = e; e = e->next; + if (((struct ip_flow *)f->v)->expire < tv.tv_sec) { + freekey(f->k); + uh->entrycount--; + if (f->v != NULL) + free(f->v); + free(f); + flows_expired++; + } + } + } + + pthread_mutex_unlock(&inQ.fq_mtx); + + syslog(LOG_WARNING, "expired %u flows", flows_expired); + } + + return (NULL); +} + /* * NOTE: The protocol list (plist) passed as an argument is a global * variable. It is accessed from 3 functions: classify_pthread, @@ -840,12 +997,20 @@ static int read_config(const char *file, struct ic_protocols *plist) { + enum { bufsize = 2048 }; struct protocol *proto; properties props; - const char *errmsg, *name, *value; - int fd; + const char *errmsg, *name; + char *value; + int fd, fdpf; uint16_t rule; + char **ap, *argv[bufsize]; + fdpf = open("/dev/pf", O_RDONLY); + if (fdpf == -1) { + syslog(LOG_ERR, "unable to open /dev/pf"); + return (EX_OSERR); + } fd = open(file, O_RDONLY); if (fd == -1) { syslog(LOG_ERR, "unable to open configuration file"); @@ -863,10 +1028,48 @@ /* Do not match traffic against this pattern */ if (value == NULL) continue; - rule = strtonum(value, 1, 65535, &errmsg); - if (rule == 0) { + for (ap = argv; (*ap = strsep(&value, " \t")) != NULL;) + if (**ap != '\0') + if (++ap >= &argv[bufsize]) + break; + if (!strncmp(argv[0], "queue", strlen("queue"))) { + if (ioctl(fdpf, DIOCGETNAMEDALTQ, &rule)) { + syslog(LOG_WARNING, + "could not get ALTQ translation for" + " queue %s", argv[1]); + continue; + } + if (rule == 0) { + syslog(LOG_WARNING, + "queue %s does not exists!", argv[1]); + continue; + } + } else if (!strncmp(argv[0], "dnqueue", strlen("dnqueue"))) + rule = strtonum(argv[1], 1, 65535, &errmsg); + else if (!strncmp(argv[0], "dnpipe", strlen("dnpipe"))) + rule = strtonum(argv[1], 1, 65535, &errmsg); + else if (!strncmp(argv[0], "tag", strlen("tag"))) { + if (ioctl(fdpf, DIOCGETNAMEDTAG, &rule)) { + syslog(LOG_WARNING, + "could not get tag translation for" + " queue %s", argv[1]); + continue; + } + if (rule == 0) { + syslog(LOG_WARNING, + "tag %s does not exists!", argv[1]); + continue; + } + } else if (!strncmp(argv[0], "action", strlen("action"))) { + if (strncmp(argv[1], "block", strlen("block"))) + rule = PF_DROP; + else if (strncmp(argv[1], "allow", strlen("allow"))) + rule = PF_PASS; + else + continue; + } else { syslog(LOG_WARNING, - "invalid rule number for %s protocol: %s", + "invalid action specified for %s protocol: %s", proto->p_name, errmsg); continue; } @@ -953,10 +1156,14 @@ static void usage(const char *arg0) { - printf("usage: %s [-h] [-c file] [-p port] [-P dir] [-q length]\n", basename(arg0)); + printf("usage: %s [-h] [-c file] [-e seconds] [-n packets] " + "[-p port] [-P dir] [-q length]\n", basename(arg0)); printf("usage: %s -t -P dir\n", basename(arg0)); printf( " -c file : path to configuration file\n" + " -e secs : number of seconds before a flow is expired\n" " -h : this help screen\n" + " -n packets: number of packets before the garbage collector" + " tries to expire flows\n" " -P dir : directory containing protocol patterns\n" " -p port : port number of divert socket\n" " -q length : max length (in packets) of in/out queues\n" -- Ermal From owner-freebsd-net@FreeBSD.ORG Sat Aug 9 05:17:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA990106564A for ; Sat, 9 Aug 2008 05:17:18 +0000 (UTC) (envelope-from jacoblowens@gmail.com) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.182]) by mx1.freebsd.org (Postfix) with ESMTP id E637A8FC18 for ; Sat, 9 Aug 2008 05:17:17 +0000 (UTC) (envelope-from jacoblowens@gmail.com) Received: by ik-out-1112.google.com with SMTP id c30so1898734ika.3 for ; Fri, 08 Aug 2008 22:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=HRMaLvYVHirlN+X560HRk6nyDw8puGdE/Nrjs0cqoak=; b=XkhDpMvQMTun5RoVUa4b2IuDiYaKmoiTEq8TEJwvcHK2qgIqUx41MuckUSrhgHdpTj QzfD2HEHHkH2QogWpEL5BC2HKI5Fa/dNIqiwJHOVe6qarkA6TBwnVRGBCY1tux+jGf2+ vSVm1xpGyLumUjfX5GBYMqksTVMy9Vbm1nrhc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=cR1+yJerwnejfvmz8HZs8FpV2mBMdDcMD6UXSJ0JHWrl2VzXY+/9aDHtz5m0V8t5vk BaBcko/UhF/yVPYCnovQYpR/czig251EpWQpT97srXf7c9u9ET63RETD3/2SOlb+wn2v KS1sOGQWzDLU/UxtSBiWyActW6y9V+TzqufWQ= Received: by 10.210.75.6 with SMTP id x6mr6458260eba.68.1218257367920; Fri, 08 Aug 2008 21:49:27 -0700 (PDT) Received: by 10.210.80.12 with HTTP; Fri, 8 Aug 2008 21:49:27 -0700 (PDT) Message-ID: Date: Fri, 8 Aug 2008 23:49:27 -0500 From: "Jacob Owens" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: lagg failover not automatic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2008 05:17:18 -0000 Hello. I've got a old sun V100 which features two gigabit ports (using dc driver). I've been trying to get lagg failover working. on SPARC64 7.0 RELEASE On the box I put the following in /etc/rc.conf: ifconfig_dc0="UP" ifconfig_dc1="UP" cloned_interfaces="lagg0" ifconfig_lagg0="laggproto failover laggport dc0 laggport dc1 50.40.0.3netmask 255.255.0.0 I even added this to my loader.conf (per the man page) if_lagg_load="YES" I'm not using a smart switch, so no STP. What happens when I unplug the "master" interface, is that the network will stop working. the second I type in 'ifconfig -v' to see what the situation is, there is a small pause, and then the network fails over to the second nic and starts working. So it seems that typing 'ifconfig' somehow wakes the config up... Dmesg does not show the appropriate update (dc0: link state changed to DOWN/dc0: link state changed to UP) until after i type ifconfig either. Here is the before and after outfut of 'ifconfig -v' BEFORE: sunbox# ifconfig -v dc0: flags=8843 metric 0 mtu 1500 options=8 ether 00:03:ba:6c:be:04 media: Ethernet autoselect (100baseTX ) status: active lagg: laggdev lagg0 dc1: flags=8843 metric 0 mtu 1500 options=8 ether 00:03:ba:6c:be:04 media: Ethernet autoselect (100baseTX ) status: active lagg: laggdev lagg0 lo0: flags=8049 metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff000000 groups: lo lagg0: flags=8843 metric 0 mtu 1500 options=8 ether 00:03:ba:6c:be:04 inet 50.40.0.3 netmask 0xffff0000 broadcast 50.40.255.255 media: Ethernet autoselect status: active groups: lagg laggproto failover laggport: dc1 flags=0<> laggport: dc0 flags=5 AFTER: sunbox# ifconfig -v dc0: flags=8843 metric 0 mtu 1500 options=8 ether 00:03:ba:6c:be:04 media: Ethernet autoselect (none) status: no carrier lagg: laggdev lagg0 dc1: flags=8843 metric 0 mtu 1500 options=8 ether 00:03:ba:6c:be:04 media: Ethernet autoselect (100baseTX ) status: active lagg: laggdev lagg0 lo0: flags=8049 metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff000000 groups: lo lagg0: flags=8843 metric 0 mtu 1500 options=8 ether 00:03:ba:6c:be:04 inet 50.40.0.3 netmask 0xffff0000 broadcast 50.40.255.255 media: Ethernet autoselect status: active groups: lagg laggproto failover laggport: dc1 flags=4 laggport: dc0 flags=1 Thanks in advance. any ideas? From owner-freebsd-net@FreeBSD.ORG Sat Aug 9 05:57:56 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 180831065673 for ; Sat, 9 Aug 2008 05:57:56 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 9F0978FC12 for ; Sat, 9 Aug 2008 05:57:55 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 691262BD18; Sat, 9 Aug 2008 17:57:54 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0wwsqAYU9wa; Sat, 9 Aug 2008 17:57:49 +1200 (NZST) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Sat, 9 Aug 2008 17:57:49 +1200 (NZST) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 6B56E1142A; Sat, 9 Aug 2008 17:57:49 +1200 (NZST) Date: Fri, 8 Aug 2008 22:57:49 -0700 From: Andrew Thompson To: Jacob Owens Message-ID: <20080809055749.GA95107@citylink.fud.org.nz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-net@freebsd.org Subject: Re: lagg failover not automatic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2008 05:57:56 -0000 On Fri, Aug 08, 2008 at 11:49:27PM -0500, Jacob Owens wrote: > Hello. > > I've got a old sun V100 which features two gigabit ports (using dc driver). > I've been trying to get lagg failover working. on SPARC64 7.0 RELEASE > > On the box I put the following in /etc/rc.conf: > ifconfig_dc0="UP" > ifconfig_dc1="UP" > cloned_interfaces="lagg0" > ifconfig_lagg0="laggproto failover laggport dc0 laggport dc1 50.40.0.3netmask > 255.255.0.0 > > I even added this to my loader.conf (per the man page) > if_lagg_load="YES" > > I'm not using a smart switch, so no STP. > > What happens when I unplug the "master" interface, is that the network will > stop working. the second I type in 'ifconfig -v' to see what the situation > is, there is a small pause, and then the network fails over to the second > nic and starts working. So it seems that typing 'ifconfig' somehow wakes the > config up... Dmesg does not show the appropriate update (dc0: link state > changed to DOWN/dc0: link state changed to UP) until after i type ifconfig > either. Here is the before and after outfut of 'ifconfig -v' lagg (failover/loadbalance) relies on the hardware/driver reporting the link state changes to do failover, its the only way it can tell if the link has gone down. Running ifconfig will cause the hardware media to be polled as it needs the current state for the 'media: ...' line, this will cause the needed linkstate event to happen since it is different to the stored value. This is meant to happen automatically, this is a bug in the dc driver. One thing to note is that LACP mode does not have this problem as heartbeat frames are exchanged with the peer, apart from being slower as its a timeout vs link event. cheers, Andrew From owner-freebsd-net@FreeBSD.ORG Sat Aug 9 08:56:33 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18079106567B for ; Sat, 9 Aug 2008 08:56:33 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by mx1.freebsd.org (Postfix) with ESMTP id D75F68FC0C for ; Sat, 9 Aug 2008 08:56:32 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2066777rvf.43 for ; Sat, 09 Aug 2008 01:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=YWYRMiYFz28S4nObtydq5/I+HlTIllJ4z4Ynzugd2k8=; b=qDeeLo89I+5jEbAh8HwsstoHQ3nlkqfyiBnTvers/wH0JC546uVXk9580wvwL8CXwf SmzYo/vl1FqpnSO7ap0AvSktpqRy50j+r2hIiFNe0AWmPcFuS1l4enjPzWfkrKhMWdBj uQ0Y9BxUOy5PVpOj8stsRclcVTnuHw5EHWgg4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=HBZ2Q+xTAP5kEhuuuUkMPyCXMdSUW820duK5FrUUGoelzx6wObENrbAUMWC1T2IuFR /QH+bln2xYTaxM0cKo5hpoU8YjpEryWnI7nYNu6sZrDIzbTSqcDWOTGbbO8uekDe5EiS aAKdEHEQZwTCGXiDWN5gk0uH8spKzK34G2v3s= Received: by 10.141.29.21 with SMTP id g21mr1988616rvj.225.1218270471013; Sat, 09 Aug 2008 01:27:51 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id f21sm559611rvb.0.2008.08.09.01.27.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 09 Aug 2008 01:27:49 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m798Pd7a043815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Aug 2008 17:25:39 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m798PdFS043814; Sat, 9 Aug 2008 17:25:39 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sat, 9 Aug 2008 17:25:39 +0900 From: Pyun YongHyeon To: Jacob Owens Message-ID: <20080809082539.GC42339@cdnetworks.co.kr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: lagg failover not automatic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2008 08:56:33 -0000 On Fri, Aug 08, 2008 at 11:49:27PM -0500, Jacob Owens wrote: > Hello. > > I've got a old sun V100 which features two gigabit ports (using dc driver). > I've been trying to get lagg failover working. on SPARC64 7.0 RELEASE > > On the box I put the following in /etc/rc.conf: > ifconfig_dc0="UP" > ifconfig_dc1="UP" > cloned_interfaces="lagg0" > ifconfig_lagg0="laggproto failover laggport dc0 laggport dc1 50.40.0.3netmask > 255.255.0.0 > > I even added this to my loader.conf (per the man page) > if_lagg_load="YES" > > I'm not using a smart switch, so no STP. > > What happens when I unplug the "master" interface, is that the network will > stop working. the second I type in 'ifconfig -v' to see what the situation > is, there is a small pause, and then the network fails over to the second > nic and starts working. So it seems that typing 'ifconfig' somehow wakes the > config up... Dmesg does not show the appropriate update (dc0: link state > changed to DOWN/dc0: link state changed to UP) until after i type ifconfig > either. Here is the before and after outfut of 'ifconfig -v' > > BEFORE: > sunbox# ifconfig > -v > dc0: flags=8843 metric 0 mtu > 1500 > > options=8 > ether > 00:03:ba:6c:be:04 > media: Ethernet autoselect (100baseTX > ) > status: > active > lagg: laggdev > lagg0 > dc1: flags=8843 metric 0 mtu > 1500 > > options=8 > ether > 00:03:ba:6c:be:04 > media: Ethernet autoselect (100baseTX > ) > status: > active > lagg: laggdev > lagg0 > lo0: flags=8049 metric 0 mtu > 16384 > inet 127.0.0.1 netmask > 0xff000000 > groups: > lo > lagg0: flags=8843 metric 0 mtu > 1500 > > options=8 > ether > 00:03:ba:6c:be:04 > inet 50.40.0.3 netmask 0xffff0000 broadcast 50.40.255.255 > > media: Ethernet > autoselect > status: > active > groups: > lagg > laggproto > failover > laggport: dc1 > flags=0<> > laggport: dc0 flags=5 > > AFTER: > sunbox# ifconfig > -v > dc0: flags=8843 metric 0 mtu > 1500 > > options=8 > ether > 00:03:ba:6c:be:04 > media: Ethernet autoselect > (none) > status: no > carrier > lagg: laggdev > lagg0 > dc1: flags=8843 metric 0 mtu > 1500 > > options=8 > ether > 00:03:ba:6c:be:04 > media: Ethernet autoselect (100baseTX > ) > status: > active > lagg: laggdev > lagg0 > lo0: flags=8049 metric 0 mtu > 16384 > inet 127.0.0.1 netmask > 0xff000000 > groups: > lo > lagg0: flags=8843 metric 0 mtu > 1500 > > options=8 > ether > 00:03:ba:6c:be:04 > inet 50.40.0.3 netmask 0xffff0000 broadcast 50.40.255.255 > > media: Ethernet > autoselect > status: > active > groups: > lagg > laggproto > failover > laggport: dc1 > flags=4 > laggport: dc0 flags=1 > > Thanks in advance. any ideas? Would you show me the dmesg output? -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Sat Aug 9 10:09:56 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14CCB1065674 for ; Sat, 9 Aug 2008 10:09:56 +0000 (UTC) (envelope-from rfrench@freebsd.org) Received: from oberon.wxnz.net (oberon.wxnz.net [58.28.6.13]) by mx1.freebsd.org (Postfix) with ESMTP id CF8BB8FC12 for ; Sat, 9 Aug 2008 10:09:55 +0000 (UTC) (envelope-from rfrench@freebsd.org) Received: from mini-tank.local (ip-58-28-152-154.static-xdsl.xnet.co.nz [58.28.152.154]) by oberon.wxnz.net (Postfix) with ESMTP id 8D4102BBF40 for ; Sat, 9 Aug 2008 22:13:01 +1200 (NZST) From: Ryan French To: freebsd-net@freebsd.org Date: Sat, 9 Aug 2008 22:09:55 +1200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808092209.55478.rfrench@freebsd.org> Subject: Looking for the FreeBSD equivalent of an OpenBSD function X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2008 10:09:56 -0000 Hi all, First of all thank you for all the help with my question yesterday, my problem today is unfortunately not something syntactical like the last one. I am working on moving over code from OpenBSDs implementation ofMPLS to FreeBSD, and I have run up against a function called 'sysctl_ifq' and I was wondering if anyone knew of an equivalent in FreeBSD. The code that calls the function is shown below. Thanks for any help. int mpls_sysctl(int *name, u_int namelen, void *oldp, size_t *oldlenp, void *newp, size_t newlen) { if (name[0] >= MPLSCTL_MAXID) return EOPNOTSUPP; /* Almost all sysctl names at this level are terminal. */ if (namelen != 1 && name[0] != MPLSCTL_IFQUEUE) return (ENOTDIR); switch (name[0]) { case MPLSCTL_IFQUEUE: return (sysctl_ifq(name + 1, namelen - 1, oldp, oldlenp, newp, newlen, &mplsintrq)); default: return sysctl_int_arr(mplsctl_vars, name, namelen, oldp, oldlenp, newp, newlen); } } From owner-freebsd-net@FreeBSD.ORG Sat Aug 9 11:30:28 2008 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABB2210656CB for ; Sat, 9 Aug 2008 11:30:28 +0000 (UTC) (envelope-from robert@fledge.watson.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 58A178FC2F for ; Sat, 9 Aug 2008 11:30:28 +0000 (UTC) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 2D13046CCB for ; Sat, 9 Aug 2008 07:13:15 -0400 (EDT) X-Return-Path: X-Received: from cyrus.watson.org ([unix socket]) by cyrus.watson.org (Cyrus v2.1.18) with LMTP; Fri, 08 Aug 2008 17:22:18 -0400 X-Sieve: CMU Sieve 2.2 X-Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by cyrus.watson.org (Postfix) with ESMTP id F236446C0B for ; Fri, 8 Aug 2008 17:22:17 -0400 (EDT) X-Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 5D637157DA1; Fri, 8 Aug 2008 21:21:23 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) X-Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id E305A1065698; Fri, 8 Aug 2008 21:21:20 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) X-Delivered-To: stable@FreeBSD.org X-Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7FDC1065670 for ; Fri, 8 Aug 2008 21:21:12 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) X-Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8ADE38FC13 for ; Fri, 8 Aug 2008 21:21:12 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) X-Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 2E71646C0B for ; Fri, 8 Aug 2008 17:21:12 -0400 (EDT) Date: Fri, 8 Aug 2008 22:21:12 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: stable@FreeBSD.org In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org ReSent-Date: Sat, 9 Aug 2008 12:13:10 +0100 (BST) ReSent-From: robert ReSent-To: net@FreeBSD.org ReSent-Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you ReSent-Message-ID: ReSent-User-Agent: Alpine 1.10 (BSF 962 2008-03-14) Cc: Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2008 11:30:28 -0000 On Sun, 3 Aug 2008, Robert Watson wrote: > This is an advance warning that, late next week, I will be merging a fairly > large set of changes to the IPv4 and IPv6 protocols layered over the > inpcb/inpcbinfo kernel infrastructure. To be specific, this affects TCP, > UDP, and raw sockets on both IPv4 and IPv6. I will post a further e-mail > announcement along with patch set and schedule in a day or two once it's > prepared. Patches, which require the MFC of rwlock try-locking, which I did earlier today: http://www.watson.org/~robert/freebsd/netperf/20080808-7stable-rwlock-inpcb.diff These incude the inpcb/inpcbinfo read/write locking changes (although not yet for raw/divert sockets). Any testing, especially with heavy UDP loads, would be much appreciated -- this are fairly complex changes, and also quite a complex MFC. Robert N M Watson Computer Laboratory University of Cambridge > > The thrust of this change is to replace the mutexes protecting the inpcb and > inpcbinfo data structures with read-write locks (rwlocks). These structures > represent, respectively, particular sockets and the global socket lists for > all socket types in IPv4 and IPv6 except for SCTP. When you run netstat, > inpcbinfo is the data structure referencing all connections, and each line in > the nestat output reflects the contents of a specific inpcb. > > In the current stage of this work, the intent is to improve performance for > datagram-related protocols on SMP systems by allowing concurrent acquisition > of both global and connection locks during receive and transmit. This is > possible because, in the common case, no connection or global state is > modified during UDP/raw receive and transmit at the IP layer, so a read lock > is sufficient to prevent data in those structures from unexpectedly changing. > For receive, socket layer state is modified, but this is separately protected > by socket layer locks. On transmit, no state is modified at any layer, so in > principle we will allow fully parallel transmit from multiple threads down to > about the routing and network interface layers, whereas previously they would > bottleneck in UDP. > > The applications targeted by this change are threaded UDP server > applications, such as BIND9, nsd, and UDP-based memcached. Kris Kennaway and > Paul Saab have done fairly extensive testing with the changes and > demonstrated significant performance improvements due to reduced contention > and overhead. Perhaps they can mention some of those numbers in a follow-up > to this post. > > The reason for the heads up is that, while carefully-tested, changes of this > sort do come with risks. We've carefully structured them so as to avoid > breaking the ABIs for netstat, etc, but it's not impossible that some > problems will arise as the changes settle. The goal, however, is to see > these performance improvements in 7.1, and since they've had a bit to shake > out in 8.x and seen some heavy use, I think now is the right time to merge > them. > > In any case, I will send out e-mail in a couple of days with a proposed merge > patch and schedule for merging, and perhaps if you are in a positition where > you might benefit from these improvements, or have interesting UDP or > raw-socket based applications running on 7.x, you could test the candidate > patch before it's merged, reporting any problems. Unless I receive negative > feedback, I will plan on merging the changes late in the week, and keep a > close eye on stable@ for any reports of problems. > > Thanks, > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Aug 9 11:36:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AA64106566C for ; Sat, 9 Aug 2008 11:36:27 +0000 (UTC) (envelope-from ady@ady.ro) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by mx1.freebsd.org (Postfix) with ESMTP id 2C8FF8FC0A for ; Sat, 9 Aug 2008 11:36:26 +0000 (UTC) (envelope-from ady@ady.ro) Received: by wf-out-1314.google.com with SMTP id 24so1076369wfg.7 for ; Sat, 09 Aug 2008 04:36:26 -0700 (PDT) Received: by 10.142.240.9 with SMTP id n9mr1335298wfh.6.1218281786423; Sat, 09 Aug 2008 04:36:26 -0700 (PDT) Received: by 10.142.80.3 with HTTP; Sat, 9 Aug 2008 04:36:26 -0700 (PDT) Message-ID: <78cb3d3f0808090436h565dbe9foea6cf8df55c3cf14@mail.gmail.com> Date: Sat, 9 Aug 2008 13:36:26 +0200 From: "Adrian Penisoara" Sender: ady@ady.ro To: "Ryan French" In-Reply-To: <200808092209.55478.rfrench@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808092209.55478.rfrench@freebsd.org> X-Google-Sender-Auth: 7dc7ec914013d81b Cc: freebsd-net@freebsd.org Subject: Re: Looking for the FreeBSD equivalent of an OpenBSD function X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2008 11:36:27 -0000 Hi, On Sat, Aug 9, 2008 at 12:09 PM, Ryan French wrote: > Hi all, > > First of all thank you for all the help with my question yesterday, my problem > today is unfortunately not something syntactical like the last one. > > I am working on moving over code from OpenBSDs implementation ofMPLS to > FreeBSD, and I have run up against a function called 'sysctl_ifq' and I was > wondering if anyone knew of an equivalent in FreeBSD. The code that calls the > function is shown below. Thanks for any help. You mean the following one: http://fxr.watson.org/fxr/source/net/if.c?v=OPENBSD#L1944 In FreeBSD I think one can extract the values for queue (maximum) length and drops stats from the ifq structure using the _IF_DROP()/_IF_QLEN() macros here: http://fxr.watson.org/fxr/source/net/if_var.h?im=bigexcerpts#L247 I'm not sure whether you might need to use locking primitives to query these values for MP reasons with IF_LOCK()/IF_UNLOCK(). Regards, Adrian. From owner-freebsd-net@FreeBSD.ORG Sat Aug 9 20:47:43 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 200661065689 for ; Sat, 9 Aug 2008 20:47:43 +0000 (UTC) (envelope-from mailnull@mips.inka.de) Received: from mail-in-16.arcor-online.net (mail-in-16.arcor-online.net [151.189.21.56]) by mx1.freebsd.org (Postfix) with ESMTP id C68008FC19 for ; Sat, 9 Aug 2008 20:47:42 +0000 (UTC) (envelope-from mailnull@mips.inka.de) Received: from mail-in-14-z2.arcor-online.net (mail-in-14-z2.arcor-online.net [151.189.8.31]) by mail-in-16.arcor-online.net (Postfix) with ESMTP id C99DE1F7226 for ; Sat, 9 Aug 2008 22:12:43 +0200 (CEST) Received: from mail-in-06.arcor-online.net (mail-in-06.arcor-online.net [151.189.21.46]) by mail-in-14-z2.arcor-online.net (Postfix) with ESMTP id B4CDB100F6 for ; Sat, 9 Aug 2008 22:12:43 +0200 (CEST) Received: from lorvorc.mips.inka.de (dslb-088-067-112-132.pools.arcor-ip.net [88.67.112.132]) by mail-in-06.arcor-online.net (Postfix) with ESMTP id 9579835E731 for ; Sat, 9 Aug 2008 22:12:43 +0200 (CEST) Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.2/8.14.2) with ESMTP id m79KCgQo017300 for ; Sat, 9 Aug 2008 22:12:42 +0200 (CEST) (envelope-from mailnull@lorvorc.mips.inka.de) Received: (from mailnull@localhost) by lorvorc.mips.inka.de (8.14.2/8.14.2/Submit) id m79KCgIe017299 for freebsd-net@freebsd.org; Sat, 9 Aug 2008 22:12:42 +0200 (CEST) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Date: Sat, 9 Aug 2008 20:12:42 +0000 (UTC) Message-ID: Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-net@freebsd.org X-Virus-Scanned: ClamAV 0.93.3/7995/Sat Aug 9 20:55:20 2008 on mail-in-06.arcor-online.net X-Virus-Status: Clean Subject: Rx/tx hardware checksumming statistics? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2008 20:47:43 -0000 OpenBSD keeps count of the packets that have undergone IPv4 header/ TCP/UDP checksumming in hardware. These statics are available with netstat -s, e.g.: ip: ... 492152 input datagrams checksum-processed by hardware 911338 output datagrams checksum-processed by hardware ... This comes in quite handy to check whether checksum offloading actually works and which protocols are successfully processed this way. On FreeBSD, netstat -s does not provide this information. Are these statistics available in some other way? How would I check whether packets have actually been checksummed in hardware? -- Christian "naddy" Weisgerber naddy@mips.inka.de