From owner-freebsd-net Sun Dec 10 18:44:46 2000 From owner-freebsd-net@FreeBSD.ORG Sun Dec 10 18:44:41 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from operamail.com (OperaMail.com [199.29.68.79]) by hub.freebsd.org (Postfix) with ESMTP id 69D1E37B401 for ; Sun, 10 Dec 2000 18:44:41 -0800 (PST) X-WM-Posted-At: operamail.com; Sun, 10 Dec 00 21:44:40 -0500 X-WebMail-UserID: whelkman Date: Sun, 10 Dec 2000 21:44:40 -0500 Sender: Robert Kosinski From: Robert Kosinski To: Nick Rogness , Robert Kosinski Cc: freebsd-net X-EXP32-SerialNo: 00000000 Subject: RE: Odd TCP / DNS behavior in 4.x Message-ID: <3A34C1E7@operamail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: InterChange (Hydra) SMTP v3.61.08 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It seems no one has any idea of a solution to my problem. In that case, can anyone recommend a thorough network guide that systematically runs through the entire process of basic networking? I have tried all sorts of things, and I cannot resolve this problem. At this point I am willing to try anything. I really enjoy FreeBSD, but I cannot use it if it will not function correctly. I'd prefer not to switch to another OS, but this problem is holding back my plans. Any suggestions at all would be appreciated. Thanks again, all. >===== Original Message From Robert Kosinski ===== >Thank you for your prompt reply, Mr. Rogness. > >> Did you try running on different hardware? > >No, but I do not see how the outgoing device can be at fault. >The outgoing device is a US Robotics 56K Voice/Fax modem (yuck, >I know). It has given me flawless operation under several >operating systems and even appears to function normally under >FreeBSD. As I said, there are no problems NAT-ting through the >box, just using the FreeBSD machine itself. The only hardware >I have to swap in place of it is another USR 56k modem. > >> Any unusual syslog entries? > >There aren't any normal syslog entries at all, but if I browse >through Squid, I receive the following log entries in access.log >several minutes after attempting to access the site: > >975964740.216 240966 192.168.0.2 TCP_MISS/504 1039 GET >http://litestep.org/ - DIRECT/litestep.org - > >Of course, I have attempted to connect to litestep.org (which is >just a redirect to litestep.net which does not work, either). > >975965019.609 241570 192.168.0.2 TCP_MISS/504 1041 GET >http://209.116.0.210/ - DIRECT/209.116.0.210 - > >I resolved litestep.org to its IP, 209.116.0.210, and attempted to >connect to that. litestep.org, www.litestep.org, litestep.net, and >www.litestep.net all share the same IP. > >A 504 is a gateway timeout, I know, but that's about all I can say >regarding it. Just to refresh, by turning off Squid (which resides >on the FreeBSD box) and connecting to a site without it from a >machine behind the firewall (i.e. using packet forwarding), the site >will load correctly. > >> Are you running bind? > >No. > >> Rule #100 and #200 never get used in the above ruleset. Move them >> to before the natd statement. > >I was wondering about that. I didn't think there was a chance they >would get used, either. Truth is, I just ripped that off of FreeBSD >Diary and never paid attention to the rules since those and the >FreeBSD shipped "open" ruleset function the same as far as connections >from the physical FreeBSD machine are concerned. > >> If you are going to use rule numbers use rule numbers on every rule. >> Makes it easier to understand (IMO). > >I agree. Whenever I get around to writing my own firewall, I will place >numbers before each rule, but that firewall isn't mine. > >> What is the output of `ipfw -a l' ? > >After moving 100 and 200 above the natd statement per your suggestion, >the output is: > >00100 0 0 allow ip from any to any via lo0 >00200 0 0 deny ip from any to 127.0.0.0/8 >00300 20 1767 divert 8668 ip from any to any via tun0 >00400 274 15868 allow ip from any to any >65535 4 237 deny ip from any to any > >> Turn off deny_incoming while testing. > >Done. > >Well, that's about all I can say for now. Thank you very much for your reply. >I appreciate it. >===== Original Message From Nick Rogness ===== >On Mon, 4 Dec 2000, Robert Kosinski wrote: > > Hard to say what it is. Did you try running on different > hardware? Any unusual syslog entries? More comments below. > > >> I am using FreeBSD 4.2-STABLE (CTM 4.0342), but this problem has persisted >> throughout several upgrades of the machine. This box is used as a packet >> filtering firewall with network address translation for a small, private >> class-C >> network (192.168.0.0/24). Besides a minor problem with ICQ logging off about >> every ten minutes and then coming back on, all machines behind the firewall >> have >> as normal TCP, UDP, etc. access as you could expect from NAT. >> >> The problem is: TCP access on the actual FreeBSD machine is flaky at best. >> For >> some reason, I can only connect to about 50% of all sites I have attempted. >> This problem affects FTP (and the ports collection), HTTP (and the Squid >> proxy), >> and probably all TCP-based traffic. The same 50% of the sites I cannot access >> remain constant. ICMP (ping and traceroute) seems not affected. >> >> What appears to happen on the "dead" sites is a DNS lookup and an eventual >> timeout. The same DNS servers are used by the FreeBSD machine as well as >> machines behind the firewall, so I do not believe I am a victim of defective >> DNS >> servers. > > Are you running bind? If so, your /etc/resolv.conf file should > look someting like: > > domain domainname.com > nameserver 127.0.0.1 > > You should be querying your local nameserver before going out to > ask others. Do you have forwarders configured? > > >Manually resolving the IPs of affected sites and attempting to >> connect >> to the IP results in failure as well. >> >> I know this is not a problem with the NAT configuration because I have shut >> off >> NAT completely and used the FreeBSD machine as a regular client. Of course >> the >> problem persists. >> >> I have to load at least a minimal IPFW rule set since the machine's ports are >> closed by default. For now, I am using a minor variation of the "open" rule >> set >> from FreeBSD's default rc.firewall. Neither the original rc.firewall rule set >> nor the set I'm using result in proper communication from the physical FreeBSD >> machine. >> >> For record, the IPFW rule set is >> >> /sbin/ipfw -f flush >> /sbin/ipfw add divert natd all from any to any via tun0 >> /sbin/ipfw add pass all from any to any >> /sbin/ipfw add 100 pass all from any to any via lo0 >> /sbin/ipfw add 200 deny all from any to 127.0.0.0/8 >> > > What is the output of `ipfw -a l' ? If you are going to use > rule numbers use rule numbers on every rule. Makes it easier to > understand (IMO). Rule #100 and #200 never get used in the above > ruleset. Move them to before the natd statement. > >> and the natd rule set is >> >> log no >> deny_incoming no >> same_ports yes >> dynamic yes >> verbose no >> interface tun0 >> redirect_port tcp 192.168.0.2:2000-2020 2000-2020 >> > > Turn off deny_incoming while testing. > >Nick Rogness >- Drive defensively. Buy a tank. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Dec 10 19:12:32 2000 From owner-freebsd-net@FreeBSD.ORG Sun Dec 10 19:12:29 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from shell6.ba.best.com (shell6.ba.best.com [206.184.139.137]) by hub.freebsd.org (Postfix) with ESMTP id C343F37B401 for ; Sun, 10 Dec 2000 19:12:29 -0800 (PST) Received: from fitz (root@localhost [127.0.0.1]) by shell6.ba.best.com (8.9.3/8.9.2/best.sh) with SMTP id TAA21703 for ; Sun, 10 Dec 2000 19:12:12 -0800 (PST) Message-ID: <002c01c06320$269cfde0$040ca8c0@fitz> From: "John Fitzgibbon" To: Subject: Etherboot 4.6.1 and FreeBSD 4.2 Release Date: Sun, 10 Dec 2000 19:11:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Anyone know if this combination works? I'm trying to use Etherboot 4.6.1's ne.com, (vanilla compile from the ports collection), to diskless boot a 4.2 Release kernel. On the client, ne.com recognizes the kernel as FreeBSD/ELF and loads it from the server. However, on switching to the kernel I immediately get the following: Fatal trap 12: page fault while in vm86 mode... fault code = user read, page not present... panic page fault ... and I'm hosed. The kernel is compiled with the BOOTP options, (but it looks like its not even loaded properly). Any suggestions/alternatives would be appreciated. Cheers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 11 3:58:57 2000 From owner-freebsd-net@FreeBSD.ORG Mon Dec 11 03:58:52 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6C2537B6E5; Mon, 11 Dec 2000 03:58:13 -0800 (PST) Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8748C6E2FE0; Mon, 11 Dec 2000 01:49:52 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBB9mbv23357; Mon, 11 Dec 2000 01:48:37 -0800 (PST) Date: Mon, 11 Dec 2000 01:48:37 -0800 From: Alfred Perlstein To: bmilekic@freebsd.org Cc: net@freebsd.org Subject: Abusing m_ext for a worthy goal. Message-ID: <20001211014837.W16205@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: bright@fw.wintelcom.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ok, part of the mp cleanup got me looking at af_unix sockets. Here's the deal, descriptors can be called "in-flight" meaning they have been passed from one application to another via CMG_DATA but not picked up on the other side yet. The kernel does a bunch of hokey stuff to garbage collect them. Instead of doing that I'd like to abuse MEXTADD to setup a callback to remove the references automagicaly when the mbuf it free'd. Here's the problem: I want to use the mbuf clusters, I don't want to use any special external storage. I want my callback to free the cluster. Any hints on how to do this? here's what I have so far: MEXTADD(control, mtod(control, char *), control->m_len, unp_mbfree, cm, M_RDONLY, EXT_CMSG_DATA); control is a mbuf with a cluster attached the has fd's written in it. cm is a pointer to the mbuf cluster. static void unp_mbfree(caddr_t mm, void *claddr) { struct mbuf *m = (struct mbuf *)mm; unp_scan(m, unp_discard); _MCLFREE(claddr); } does this look right? would you like to abstract the mbuf clusters further before i started using the _ macros? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 11 3:59: 4 2000 From owner-freebsd-net@FreeBSD.ORG Mon Dec 11 03:58:58 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69ACB37B6F2 for ; Mon, 11 Dec 2000 03:58:14 -0800 (PST) Received: from bart.esiee.fr (bart.esiee.fr [147.215.1.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B8006E2E33 for ; Mon, 11 Dec 2000 00:32:03 -0800 (PST) Received: (from bonnetf@localhost) by bart.esiee.fr (8.11.1/8.11.1) id eBB8U6c08739; Mon, 11 Dec 2000 09:30:06 +0100 (MET) From: Frank Bonnet Message-Id: <200012110830.eBB8U6c08739@bart.esiee.fr> Subject: Re: NAT & IRC To: wes@softweyr.com Date: Mon, 11 Dec 2000 9:30:06 MET Cc: matt@gsicomp.on.ca, mike@argos.org, freebsd-net@FreeBSD.ORG In-Reply-To: <3A31C7FA.79B0E7E5@softweyr.com>; from "Wes Peters" at Dec 08, 2000 10:49 pm X-Mailer: Elm [revision: 212.5] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Use an identd that refuses to disclose information about your systems by > returning a random ident string. If you use a NAT router, run it on the > router. If not, configure your router to redirect all ident requests to > one machine that has such an ident server running. > yes ! ident2 does the job , see at FreeBSD lastests ports ( -r option ) -- Frank Bonnet Systemes et Reseaux UNIX Groupe ESIEE Paris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 11 8:19:12 2000 From owner-freebsd-net@FreeBSD.ORG Mon Dec 11 08:19:10 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (law2-f51.hotmail.com [216.32.181.51]) by hub.freebsd.org (Postfix) with ESMTP id 0887E37B400 for ; Mon, 11 Dec 2000 08:19:10 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 11 Dec 2000 08:19:09 -0800 Received: from 204.124.82.48 by lw2fd.hotmail.msn.com with HTTP; Mon, 11 Dec 2000 16:19:09 GMT X-Originating-IP: [204.124.82.48] From: "Mark Wright" To: freebsd-net@freebsd.org Cc: markscottwright@hotmail.com Subject: Confusing netgraph error Date: Mon, 11 Dec 2000 16:19:09 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Dec 2000 16:19:09.0803 (UTC) FILETIME=[178D83B0:01C0638E] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm trying to get frame relay working with a lmc1200 card, and I'm getting the following error: sj# ngctl mkpeer lmc0: frame_relay rawdata downstream sj# ngctl mkpeer lmc0:rawdata lmi dlci0 auto0 sj# ngctl mkpeer lmc0:rawdata rfc1490 dlci15 downstream ngctl: send msg: No such file or directory What does that mean? Should I be concerned that ifconfig -a doesn't reveal the lmc0? Or does it show up only after I do a 'ngctl interface'? It shows up in dmesg: lmc0: port 0xf880-0xf8ff mem 0xffbefc00-0xffbefc7f irq 11 at device 16.0 on pci0 lmc0: pass 2.2, serial 00:60:99:00:23:6d lmc0: driver is using old-style compatability shims I'm using the 20001210 snapshot, and the following changes were made to my kernel config: options NETGRAPH #enable netgraph networking options NETGRAPH_SOCKET #enable netgraph networking options NETGRAPH_FRAME_RELAY #enable frame relay options NETGRAPH_LMI #enable link management ... device lmc # LanMedia card Mark markscottwright@hotmail.com _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 11 8:40:31 2000 From owner-freebsd-net@FreeBSD.ORG Mon Dec 11 08:40:27 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from alpo.whistle.com (s206m1.whistle.com [207.76.206.1]) by hub.freebsd.org (Postfix) with ESMTP id E668F37B400 for ; Mon, 11 Dec 2000 08:40:26 -0800 (PST) Received: from [10.1.10.113] (m169.whistle.com [207.76.207.169]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id IAA56908; Mon, 11 Dec 2000 08:35:25 -0800 (PST) Mime-Version: 1.0 X-Sender: mark@207.76.206.1 Message-Id: In-Reply-To: References: Date: Mon, 11 Dec 2000 08:35:19 -0800 To: "Mark Wright" , freebsd-net@FreeBSD.ORG From: Mark Peek Subject: Re: Confusing netgraph error Content-Type: multipart/alternative; boundary="============_-1235569972==_ma============" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --============_-1235569972==_ma============ Content-Type: text/plain; charset="us-ascii" At 4:19 PM +0000 12/11/00, Mark Wright wrote: >I'm trying to get frame relay working with a lmc1200 card, and I'm getting >the following error: > >sj# ngctl mkpeer lmc0: frame_relay rawdata downstream >sj# ngctl mkpeer lmc0:rawdata lmi dlci0 auto0 >sj# ngctl mkpeer lmc0:rawdata rfc1490 dlci15 downstream >ngctl: send msg: No such file or directory > >What does that mean? Should I be concerned that ifconfig -a doesn't reveal >the lmc0? Or does it show up only after I do a 'ngctl interface'? It shows >up in dmesg: Well, Archie and Julian are the experts on these things :-) but I think this might work for you. Give it a try... ngctl mkpeer lmc0: frame_relay rawdata downstream ngctl mkpeer lmc0:rawdata lmi dlci0 auto0 ngctl connect lmc0:rawdata lmc0:rawdata.dlci0 dlci1023 auto1023 ngctl mkpeer lmc0:rawdata rfc1490 dlci15 downstream ngctl mkpeer lmc0:rawdata.dlci15 iface inet inet ifconfig ngX 1.2.3.4 5.6.7.8 netmask 255.255.255.255 Mark --------- Mark Peek Director of Internet Technology IBM Global Small Business/Whistle Communications Work: (650) 577-7052 Email: mark@whistle.com --============_-1235569972==_ma============ Content-Type: text/html; charset="us-ascii" Re: Confusing netgraph error
At 4:19 PM +0000 12/11/00, Mark Wright wrote:
>I'm trying to get frame relay working with a lmc1200 card, and I'm getting
>the following error:
>
>sj# ngctl mkpeer lmc0: frame_relay rawdata downstream
>sj# ngctl mkpeer lmc0:rawdata lmi dlci0 auto0
>sj# ngctl mkpeer lmc0:rawdata rfc1490 dlci15 downstream
>ngctl: send msg: No such file or directory
>
>What does that mean? Should I be concerned that ifconfig -a doesn't reveal
>the lmc0?  Or does it show up only after I do a 'ngctl interface'?  It shows
>up in dmesg:

Well, Archie and Julian are the experts on these things :-) but I think this might work for you. Give it a try...

  ngctl mkpeer lmc0: frame_relay rawdata downstream
  ngctl mkpeer lmc0:rawdata lmi dlci0 auto0
  ngctl connect lmc0:rawdata lmc0:rawdata.dlci0 dlci1023 auto1023
  ngctl mkpeer lmc0:rawdata rfc1490 dlci15 downstream
  ngctl mkpeer lmc0:rawdata.dlci15 iface inet inet
  ifconfig ngX 1.2.3.4 5.6.7.8 netmask 255.255.255.255


Mark

---------
Mark Peek
Director of Internet Technology
IBM Global Small Business/Whistle Communications
Work:  (650) 577-7052      Email: mark@whistle.com
--============_-1235569972==_ma============-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 11 8:55:19 2000 From owner-freebsd-net@FreeBSD.ORG Mon Dec 11 08:55:14 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mgw1.MEIway.com (mgw1.meiway.com [212.73.210.75]) by hub.freebsd.org (Postfix) with ESMTP id 1452E37B400 for ; Mon, 11 Dec 2000 08:55:13 -0800 (PST) Received: from sv.Go2France.com (sv.meiway.com [212.73.210.79]) by mgw1.MEIway.com (Postfix Relay Hub) with ESMTP id 02E056A90B for ; Mon, 11 Dec 2000 17:55:06 +0100 (CET) Message-Id: <5.0.2.1.0.20001211175018.057476e0@mail.Go2France.com> X-Sender: lconrad%Go2France.com@mail.Go2France.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 11 Dec 2000 17:54:31 +0100 To: freebsd-net@freebsd.org From: Len Conrad Subject: RE: Odd TCP / DNS behavior in 4.x In-Reply-To: <3A34C1E7@operamail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Before you trash FBSD and BIND, I suggest you learn DNS, because yours is a freakin mess: DNS Expert Detailed Report for litestep.org 11/12/00, 17:48, using the analysis setting "Normal" ====================================================================== Information ---------------------------------------------------------------------- Serial number: 1999100114 Primary name server: greedo.ecsc.net. Primary mail server: pimpin.net. Number of records: 8 (1 NS, 1 MX, 1 A, 5 CNAME, 0 PTR, 0 Other) Warnings ---------------------------------------------------------------------- o The zone contains more than one authoritative name server with the same IP address The name servers "ns2.ecsc.net." and "greedo.ecsc.net.", which are authoritative for "litestep.org.", have the same IP address (209.116.0.3). o There is just one NS record in the zone The zone contains just one NS record. Every zone should contain two or more NS records, and the NS records in the zone should match the delegation data for the domain. o There is more than one PTR record for the address 209.116.0.210 The reverse domain contains more than one PTR record for the IP Address 209.116.0.210 Errors ---------------------------------------------------------------------- o The name server "ns.ecsc.net." is only listed in delegation data The server "ns.ecsc.net." is listed as being authoritative for the zone according to the delegation data, but there is no NS record for that server in the zone data. Delegation data and zone data should always match. o The name server "greedo.ecsc.net." is not listed in delegation data The server "greedo.ecsc.net." is listed as being authoritative for the zone according to the zone data, but there is no NS record for that server in the delegation data. Delegation data and zone data should always match. o CNAME and other record type(s) with the name "mail.litestep.org." There is both a CNAME record and a record of a different type with the name "mail.litestep.org.". There should never be another type of record with the same name as a CNAME record. o There are no MX records in the zone The zone contains no MX records. This will cause delivery problems for mail sent to a user in this zone. Every zone should contain at least one MX record for successful mail delivery. o The reverse record "210.0.116.209.in-addr.arpa." does not refer to the host "litestep.org." The reverse record "210.0.116.209.in-addr.arpa." refers to "pimpin.net.", but it should refer to "litestep.org.". ---------------------------------------------------------------------- end of report DNS Expert Detailed Report for litestep.net 11/12/00, 17:53, using the analysis setting "Thorough" ====================================================================== Information ---------------------------------------------------------------------- Serial number: 1999100114 Primary name server: greedo.ecsc.net. Primary mail server: pimpin.net. Number of records: 12 (1 NS, 2 MX, 1 A, 8 CNAME, 0 PTR, 0 Other) Warnings ---------------------------------------------------------------------- o The zone contains more than one authoritative name server with the same IP address The name servers "ns2.ecsc.net." and "greedo.ecsc.net.", which are authoritative for "litestep.net.", have the same IP address (209.116.0.3). o A dot is possibly missing in the host name "litestep.net.litestep.net." A part of the domain name appears more than once in the host name of the MX record "litestep.net.litestep.net.". There may be a missing dot in the host name entry. o There is just one NS record in the zone The zone contains just one NS record. Every zone should contain two or more NS records, and the NS records in the zone should match the delegation data for the domain. o There is more than one PTR record for the address 209.116.0.210 The reverse domain contains more than one PTR record for the IP Address 209.116.0.210 Errors ---------------------------------------------------------------------- o The name server "ns.ecsc.net." is only listed in delegation data The server "ns.ecsc.net." is listed as being authoritative for the zone according to the delegation data, but there is no NS record for that server in the zone data. Delegation data and zone data should always match. o The name server "greedo.ecsc.net." is not listed in delegation data The server "greedo.ecsc.net." is listed as being authoritative for the zone according to the zone data, but there is no NS record for that server in the delegation data. Delegation data and zone data should always match. o CNAME and other record type(s) with the name "mail.litestep.net." There is both a CNAME record and a record of a different type with the name "mail.litestep.net.". There should never be another type of record with the same name as a CNAME record. o There are no MX records in the zone The zone contains no MX records. This will cause delivery problems for mail sent to a user in this zone. Every zone should contain at least one MX record for successful mail delivery. o The reverse record "210.0.116.209.in-addr.arpa." does not refer to the host "litestep.net." The reverse record "210.0.116.209.in-addr.arpa." refers to "pimpin.net.", but it should refer to "litestep.net.". ---------------------------------------------------------------------- end of report http://BIND8NT.MEIway.com : Binary for ISC BIND 8.2.3 T9B for NT4 & W2K http://IMGate.MEIway.com : Build free, hi-perf, anti-spam mail gateways To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 11 9:39:25 2000 From owner-freebsd-net@FreeBSD.ORG Mon Dec 11 09:39:22 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (law2-f44.hotmail.com [216.32.181.44]) by hub.freebsd.org (Postfix) with ESMTP id 076CB37B400 for ; Mon, 11 Dec 2000 09:39:18 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 11 Dec 2000 09:39:17 -0800 Received: from 204.124.82.48 by lw2fd.hotmail.msn.com with HTTP; Mon, 11 Dec 2000 17:39:17 GMT X-Originating-IP: [204.124.82.48] From: "Mark Wright" To: mark@whistle.com, freebsd-net@FreeBSD.ORG Subject: Re: Confusing netgraph error Date: Mon, 11 Dec 2000 17:39:17 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Dec 2000 17:39:17.0642 (UTC) FILETIME=[493F86A0:01C06399] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >From: Mark Peek > >I'm trying to get frame relay working with a lmc1200 card, and I'm >getting > >the following error: > > > >sj# ngctl mkpeer lmc0: frame_relay rawdata downstream > >sj# ngctl mkpeer lmc0:rawdata lmi dlci0 auto0 > >sj# ngctl mkpeer lmc0:rawdata rfc1490 dlci15 downstream > >ngctl: send msg: No such file or directory > > > >What does that mean? Should I be concerned that ifconfig -a doesn't >reveal > >the lmc0? Or does it show up only after I do a 'ngctl interface'? It >shows > >up in dmesg: > >Well, Archie and Julian are the experts on these things :-) but I think >this might work for you. Give it a try... > > ngctl mkpeer lmc0: frame_relay rawdata downstream > ngctl mkpeer lmc0:rawdata lmi dlci0 auto0 > ngctl connect lmc0:rawdata lmc0:rawdata.dlci0 dlci1023 auto1023 I've tried adding this line, but I still get the "no such file or directory" error after this next line: > ngctl mkpeer lmc0:rawdata rfc1490 dlci15 downstream Mark. _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 11 9:43:54 2000 From owner-freebsd-net@FreeBSD.ORG Mon Dec 11 09:43:51 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id 45A5437B402 for ; Mon, 11 Dec 2000 09:43:51 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G5E00L9SZX0Q5@falla.videotron.net> for net@freebsd.org; Mon, 11 Dec 2000 12:43:48 -0500 (EST) Date: Mon, 11 Dec 2000 12:44:55 -0500 (EST) From: Bosko Milekic Subject: Re: Abusing m_ext for a worthy goal. In-reply-to: <20001211014837.W16205@fw.wintelcom.net> To: Alfred Perlstein Cc: net@freebsd.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Alfred, On Mon, 11 Dec 2000, Alfred Perlstein wrote: > Ok, part of the mp cleanup got me looking at af_unix sockets. > > Here's the deal, descriptors can be called "in-flight" meaning they > have been passed from one application to another via > CMG_DATA but not picked up on the other side yet. > > The kernel does a bunch of hokey stuff to garbage collect them. > > Instead of doing that I'd like to abuse MEXTADD to setup a callback > to remove the references automagicaly when the mbuf it free'd. > > Here's the problem: > > I want to use the mbuf clusters, I don't want to use any special > external storage. I want my callback to free the cluster. > > Any hints on how to do this? > > here's what I have so far: > > MEXTADD(control, mtod(control, char *), control->m_len, unp_mbfree, > cm, M_RDONLY, EXT_CMSG_DATA); > > control is a mbuf with a cluster attached the has fd's written in it. > cm is a pointer to the mbuf cluster. Here, the general idea is correct, but you'll have to do things this way: #define EXT_CMSG_DATA 666 /* A hack, for now. */ An allocation: /* Here make sure you're not holding any other mutex. */ mtx_enter(&mclfree.m_mtx, MTX_DEF); _MCLALLOC(control->m_ext.ext_buf, M_WAIT); /* Or M_DONTWAIT */ mtx_exit(&mclfree.m_mtx, MTX_DEF); if (control->m_ext.ext_buf != NULL) { /* Assuming you want to M_RDONLY your data. Otherwise, just change M_RDONLY to 0. */ MEXTADD(control, control->m_ext.ext_buf, MCLBYTES, unp_mbfree, cm, M_RDONLY, EXT_CMSG_DATA); if (control->m_ext.ref_cnt == NULL) { _MCLFREE(control->m_ext.ext_buf); /* Allocation of ref. counter failed, so just fail gracefully instead of panic (this should never happen, but make sure to check. */ return (ENOBUFS); } } else return (ENOBUFS); > static void > unp_mbfree(caddr_t mm, void *claddr) > { > struct mbuf *m = (struct mbuf *)mm; > > unp_scan(m, unp_discard); > _MCLFREE(claddr); > } Actually, your free routine needs to accept the address of the cluster as a first argument, and the optional argument as a second argument. According to your MEXTADD() above, your optional argument will be something called "cm." In your case, what you need to make your optional argument be is the actual mbuf "control" (you can cast it to struct mbuf *). Then, you can call unp_scan() on that mbuf (second argument) and call _MCLFREE() on the first argument, which will effectively be the address of the cluster. > does this look right? would you like to abstract the mbuf > clusters further before i started using the _ macros? Abstracting mbuf clusters is deffinately something I'm looking at doing (as you've probably seen me mention on some posts to some of the lists), but for now, the above should do. I'd rather not rush into abstracting the EXT_CLUSTER type further for now "just for the sake of abstracting it." I want to make sure that we don't lose any performance whatsoever for what concerns clusters (i.e. I'm trying to decide on whether the cost of calling a function for clusters as well is worth it at this point). Briefly, the day will come. :-) > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." Cheers, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 11 11:17:49 2000 From owner-freebsd-net@FreeBSD.ORG Mon Dec 11 11:17:46 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from web4903.mail.yahoo.com (web4903.mail.yahoo.com [216.115.106.28]) by hub.freebsd.org (Postfix) with SMTP id 4B45737B400 for ; Mon, 11 Dec 2000 11:17:46 -0800 (PST) Message-ID: <20001211191746.25563.qmail@web4903.mail.yahoo.com> Received: from [206.191.16.98] by web4903.mail.yahoo.com; Mon, 11 Dec 2000 11:17:46 PST Date: Mon, 11 Dec 2000 11:17:46 -0800 (PST) From: Michael Yeung Subject: IP aliases and TCP socket To: net@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I have a few of questions and would greatly appreciate for some advise. 1) What I want to do is to create an application that can receive packets destined to two IP addresses from different subnet/network. Essentially have a host sitting at the broader of two networks. I noticed IP aliases restrict the alias IP address to be in the same subnet/network as the primary IP address. Is that a true restriction? If so, any advise on alternative to IP alias? 2) Assume IP aliases works for my needs as stated in question1. When I send a packet out over a TCP socket connection, how can I specify which address to be used as the source IP address (i.e. primary or alias address)? 3) Assume I can use IP aliases technique to receive packet destined to different IP addresses in the same application. If I am to use a TCP socket to retrieve the packet, how can I tell which IP address what the packet destined to (i.e. the primary or alias address)? Would packets for all addresses goes to the same socket or would it be through multiple sockets? 4) Is there direct API calls to the TCP/UDP for connection creation, sending and receiving? Or do I have to go thru the socket interface. Are they tcp_open, udp_open, tcp_send, udp_send, tcp_receive and udp_receive? Where can I find these APIs and their function prototypes? thanx very much, Michael __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 11 11:56:39 2000 From owner-freebsd-net@FreeBSD.ORG Mon Dec 11 11:56:37 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id 52A0E37B400 for ; Mon, 11 Dec 2000 11:56:37 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G5F0069X62B99@falla.videotron.net> for net@FreeBSD.ORG; Mon, 11 Dec 2000 14:56:35 -0500 (EST) Date: Mon, 11 Dec 2000 14:57:43 -0500 (EST) From: Bosko Milekic Subject: Re: Abusing m_ext for a worthy goal. In-reply-to: To: Alfred Perlstein Cc: net@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Something I forgot in first Email... On Mon, 11 Dec 2000, Bosko Milekic wrote: [...] > Actually, your free routine needs to accept the address of the > cluster as a first argument, and the optional argument as a second > argument. According to your MEXTADD() above, your optional argument will > be something called "cm." In your case, what you need to make your > optional argument be is the actual mbuf "control" (you can cast it to > struct mbuf *). Then, you can call unp_scan() on that mbuf (second > argument) and call _MCLFREE() on the first argument, which will > effectively be the address of the cluster. Don't forget to also, after running _MCLFREE() on the ext_buf, to NULL out the control mbuf's ext_buf, and to remove the M_EXT bit from the mbuf if you are planning to re-use it. Basically, make sure to clean up after yourself after you forcibly free the cluster "manually." [...] Later, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 11 12:13:58 2000 From owner-freebsd-net@FreeBSD.ORG Mon Dec 11 12:13:56 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id AFFBF37B402 for ; Mon, 11 Dec 2000 12:13:56 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBBKDtD11017; Mon, 11 Dec 2000 12:13:55 -0800 (PST) Date: Mon, 11 Dec 2000 12:13:55 -0800 From: Alfred Perlstein To: Bosko Milekic Cc: net@FreeBSD.ORG Subject: Re: Abusing m_ext for a worthy goal. Message-ID: <20001211121354.E16205@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bmilekic@technokratis.com on Mon, Dec 11, 2000 at 02:57:43PM -0500 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Bosko Milekic [001211 11:56] wrote: > > Something I forgot in first Email... > > On Mon, 11 Dec 2000, Bosko Milekic wrote: > > [...] > > Actually, your free routine needs to accept the address of the > > cluster as a first argument, and the optional argument as a second > > argument. According to your MEXTADD() above, your optional argument will > > be something called "cm." In your case, what you need to make your > > optional argument be is the actual mbuf "control" (you can cast it to > > struct mbuf *). Then, you can call unp_scan() on that mbuf (second > > argument) and call _MCLFREE() on the first argument, which will > > effectively be the address of the cluster. > > Don't forget to also, after running _MCLFREE() on the ext_buf, to > NULL out the control mbuf's ext_buf, and to remove the M_EXT bit from the > mbuf if you are planning to re-use it. Basically, make sure to clean up > after yourself after you forcibly free the cluster "manually." Hmm, I think instead of doing this sort of abuse, what I should be doing is allocating an mbuf header, then allocating a mbuf cluster then attaching them using the MEXTADD() macro. I'm going to look at the code to see if there's a clean way to do this, if not can you provide an interface for allocating and free'ing clusters by themselves? thanks, -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 11 13: 0:28 2000 From owner-freebsd-net@FreeBSD.ORG Mon Dec 11 13:00:25 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 31D1037B402 for ; Mon, 11 Dec 2000 13:00:16 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 145a1g-0000D5-00; Mon, 11 Dec 2000 13:58:24 -0700 Sender: wes@FreeBSD.ORG Message-ID: <3A353FF0.1033B0A@softweyr.com> Date: Mon, 11 Dec 2000 13:58:24 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Frank Bonnet Cc: matt@gsicomp.on.ca, mike@argos.org, freebsd-net@FreeBSD.ORG Subject: Re: NAT & IRC References: <200012110830.eBB8U6c08739@bart.esiee.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Frank Bonnet wrote: > > > Use an identd that refuses to disclose information about your systems by > > returning a random ident string. If you use a NAT router, run it on the > > router. If not, configure your router to redirect all ident requests to > > one machine that has such an ident server running. > > > > yes ! ident2 does the job , see at FreeBSD lastests ports ( -r option ) So does my simple "liedentd" (short for Liars Identd), but I'm in the process of putting in the last "feature" -- a dictionary of words (or phrases) to use as the username response. When I'm finished, I'll make a port of it. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 11 13:29:35 2000 From owner-freebsd-net@FreeBSD.ORG Mon Dec 11 13:29:32 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id C12BA37B400; Mon, 11 Dec 2000 13:29:31 -0800 (PST) Received: from victoria-117.budapest.interware.hu ([195.70.63.117] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 145aVl-0001n5-00; Mon, 11 Dec 2000 22:29:29 +0100 Sender: julian@FreeBSD.ORG Message-ID: <3A34E04B.D93AFCB@elischer.org> Date: Mon, 11 Dec 2000 06:10:19 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Alfred Perlstein Cc: bmilekic@freebsd.org, net@freebsd.org Subject: Re: Abusing m_ext for a worthy goal. References: <20001211014837.W16205@fw.wintelcom.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alfred Perlstein wrote: > > Ok, part of the mp cleanup got me looking at af_unix sockets. > > Here's the deal, descriptors can be called "in-flight" meaning they > have been passed from one application to another via > CMG_DATA but not picked up on the other side yet. > > The kernel does a bunch of hokey stuff to garbage collect them. Check wih kirk as he always uses this as an example in his class of something that is tricky.. > > Instead of doing that I'd like to abuse MEXTADD to setup a callback > to remove the references automagicaly when the mbuf it free'd. > > Here's the problem: > > I want to use the mbuf clusters, I don't want to use any special > external storage. I want my callback to free the cluster. > > Any hints on how to do this? > > here's what I have so far: > > MEXTADD(control, mtod(control, char *), control->m_len, unp_mbfree, > cm, M_RDONLY, EXT_CMSG_DATA); > > control is a mbuf with a cluster attached the has fd's written in it. > cm is a pointer to the mbuf cluster. > > static void > unp_mbfree(caddr_t mm, void *claddr) > { > struct mbuf *m = (struct mbuf *)mm; > > unp_scan(m, unp_discard); > _MCLFREE(claddr); > } > > does this look right? would you like to abstract the mbuf > clusters further before i started using the _ macros? > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 11 13:30:57 2000 From owner-freebsd-net@FreeBSD.ORG Mon Dec 11 13:30:55 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from vbook.express.ru (unknown [212.24.36.221]) by hub.freebsd.org (Postfix) with ESMTP id 4724937B400 for ; Mon, 11 Dec 2000 13:30:54 -0800 (PST) Received: (from vova@localhost) by vbook.express.ru (8.9.3/8.9.3) id AAA03771; Tue, 12 Dec 2000 00:30:59 +0300 (MSK) (envelope-from vova) From: "Vladimir B. Grebenschikov" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14901.18322.579746.244810@vbook.express.ru> Date: Tue, 12 Dec 2000 00:30:58 +0300 (MSK) To: "Kenneth D. Merry" Cc: freebsd-net@FreeBSD.ORG Subject: zero copy code review In-Reply-To: <20001129231653.A1503@panzer.kdm.org> References: <20001129231653.A1503@panzer.kdm.org> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: vova@vbook.express.ru Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kenneth D. Merry writes: > http://people.FreeBSD.org/~ken/zero_copy > > There are diffs posted above against -current as of early November 28th, > along with a FAQ, and change log. > > These diffs include changes in: > > - the socket code > - NFS code > - VM code > - ti(4) driver does ti driver support 802.1q VLAN's ? if so by native card possibilities or by kernel ? > Ken > -- > Kenneth Merry > ken@kdm.org -- TSB Russian Express, Moscow Vladimir B. Grebenschikov, vova@express.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 11 13:33:27 2000 From owner-freebsd-net@FreeBSD.ORG Mon Dec 11 13:33:25 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 64FA737B400 for ; Mon, 11 Dec 2000 13:33:24 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id OAA16369; Mon, 11 Dec 2000 14:33:19 -0700 (MST) (envelope-from ken) Date: Mon, 11 Dec 2000 14:33:19 -0700 From: "Kenneth D. Merry" To: "Vladimir B. Grebenschikov" Cc: freebsd-net@FreeBSD.ORG Subject: Re: zero copy code review Message-ID: <20001211143319.A16357@panzer.kdm.org> References: <20001129231653.A1503@panzer.kdm.org> <14901.18322.579746.244810@vbook.express.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <14901.18322.579746.244810@vbook.express.ru>; from vova@express.ru on Tue, Dec 12, 2000 at 12:30:58AM +0300 Sender: ken@panzer.kdm.org Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Dec 12, 2000 at 00:30:58 +0300, Vladimir B. Grebenschikov wrote: > Kenneth D. Merry writes: > > > http://people.FreeBSD.org/~ken/zero_copy > > > > There are diffs posted above against -current as of early November 28th, > > along with a FAQ, and change log. > > > > These diffs include changes in: > > > > - the socket code > > - NFS code > > - VM code > > - ti(4) driver > > does ti driver support 802.1q VLAN's ? Yes. > if so by native card possibilities or by kernel ? Both, I think, but Bill Paul or someone more familiar with VLANs might be able to give you a better answer. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 11 13:36:32 2000 From owner-freebsd-net@FreeBSD.ORG Mon Dec 11 13:36:30 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id 54F5D37B400 for ; Mon, 11 Dec 2000 13:36:30 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G5F00BNBAO7GC@falla.videotron.net> for net@FreeBSD.ORG; Mon, 11 Dec 2000 16:36:08 -0500 (EST) Date: Mon, 11 Dec 2000 16:37:15 -0500 (EST) From: Bosko Milekic Subject: Re: Abusing m_ext for a worthy goal. In-reply-to: <20001211121354.E16205@fw.wintelcom.net> To: Alfred Perlstein Cc: net@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 11 Dec 2000, Alfred Perlstein wrote: > Hmm, I think instead of doing this sort of abuse, what I should be > doing is allocating an mbuf header, then allocating a mbuf cluster > then attaching them using the MEXTADD() macro. Alfred, I'm surprised you're pointing this out when in my first post, the code example does exactly this, minus the mbuf allocation. :-) > I'm going to look at the code to see if there's a clean way to do this, > if not can you provide an interface for allocating and free'ing > clusters by themselves? > > thanks, > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 11 13:52:51 2000 From owner-freebsd-net@FreeBSD.ORG Mon Dec 11 13:52:46 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 259DD37B400 for ; Mon, 11 Dec 2000 13:52:46 -0800 (PST) Received: from victoria-117.budapest.interware.hu ([195.70.63.117] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 145asF-0004a7-00; Mon, 11 Dec 2000 22:52:43 +0100 Sender: julian@FreeBSD.ORG Message-ID: <3A354C8A.993BC4E5@elischer.org> Date: Mon, 11 Dec 2000 13:52:10 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: mwright@pro-ns.net, net@freebsd.org Subject: Re: Is it possible to use a LanMedia LMC1200 with frame relay? References: <200012112116.eBBLGkC08624@user2.pro-ns.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org mwright@pro-ns.net wrote: > > > Julian Elischer wrote: > > > > > > mwright@pro-ns.net wrote: > > > > > > > > Does anyone have any experience using a LanMedia 1200 with frame relay? > How > > > > did they configure it? > > > > > > > > MarkScottWright@hotmail.com > > > > > > If it's supported by one of the drivers that supports netgraph then yes it > > > can do frame relay.. > > > check the examples in /usr/share/examples/netgraph and substitute in the > > > appropriate driver name. > > > > To answer my own question, the 'lmc' driver > > has the following constant in it: > > LMC_CTL_CARDTYPE_LMC1200 > > so I presume it can.. in which case, use Netgraph to > > supply your frame relay > > Julian - > > thanks for your help. I understand that you're one of the netgraph experts, > and I'm hoping that you might be able to decypher the following error message I > get. When I do the following: > > ngctl mkpeer lmc0: frame_relay rawdata downstream > ngctl mkpeer lmc0:rawdata lmi dlci0 auto0 > ngctl mkpeer lmc0:rawdata rfc1490 dlci15 downstream > > I get this error after the last command: > ngctl: send msg: No such file or directory > > What does this mean? > > This is what dmesg says, which looks right to me: > lmc0: port 0xf880-0xf8ff mem 0xffbefc00-0xffbefc7f > irq 11 at device 16.0 on pci0 > lmc0: pass 2.2, serial 00:60:99:00:23:6d > lmc0: driver is using old-style compatability shims yes but does netgraph know it;s there? ngctl list should show the lmc device: if it does not then the driver wasn't compiled with netgraph properly if it does then I would do: #make the fram mux and name it. ngctl mkpeer lmc0: frame_relay rawdata downstream ngctl name lmc0:rawdata mux #make the lmi handler and name it. connect it to 2 hooks ngctl mkpeer mux: lmi dlci0 auto0 ngctl name mux:dlci0 lmi ngctl connect mux: lmi: dlci1023 auto1023 #make an rfc1490 handler and put it on dlci 15 (if that's where it should go,) ngctl mkpeer mux: rfc1490 dlci15 downstream ngclt name mux:dlci15 rfc #put a routable interface on the stack. ngctl mkpeer rfc: iface inet inet #and ifconfig it ifconfig ng0 1.2.3.4 5.6.7.8 netmask 255.255.255.255 (having altered mark's version..) > > I've got the following additions to my kernel config (I'm using the 2000/12/10 > snapshot from current.freebsd.org): > options NETGRAPH #enable netgraph networking > options NETGRAPH_SOCKET #enable netgraph networking > options NETGRAPH_FRAME_RELAY #enable frame relay > options NETGRAPH_LMI #enable link management > options IPFIREWALL #enable ipfw > options IPDIVERT #enable ip diversion > .. > device lmc # LanMedia card > > Mark > mwright@pro-ns.net -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 11 14: 1:30 2000 From owner-freebsd-net@FreeBSD.ORG Mon Dec 11 14:01:28 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 18FB337B400 for ; Mon, 11 Dec 2000 14:01:28 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBBM1Pc15264; Mon, 11 Dec 2000 14:01:25 -0800 (PST) Date: Mon, 11 Dec 2000 14:01:25 -0800 From: Alfred Perlstein To: Bosko Milekic Cc: net@FreeBSD.ORG Subject: Re: Abusing m_ext for a worthy goal. Message-ID: <20001211140125.M16205@fw.wintelcom.net> References: <20001211121354.E16205@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bmilekic@technokratis.com on Mon, Dec 11, 2000 at 04:37:15PM -0500 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Bosko Milekic [001211 13:36] wrote: > > On Mon, 11 Dec 2000, Alfred Perlstein wrote: > > > Hmm, I think instead of doing this sort of abuse, what I should be > > doing is allocating an mbuf header, then allocating a mbuf cluster > > then attaching them using the MEXTADD() macro. > > Alfred, I'm surprised you're pointing this out when in my first post, > the code example does exactly this, minus the mbuf allocation. :-) Well i understand that, I just didn't want to put all that code in when a small abstraction would give a good api for other code that might do this. > > I'm going to look at the code to see if there's a clean way to do this, > > if not can you provide an interface for allocating and free'ing > > clusters by themselves? :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 11 14:29:54 2000 From owner-freebsd-net@FreeBSD.ORG Mon Dec 11 14:29:52 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from shell6.ba.best.com (shell6.ba.best.com [206.184.139.137]) by hub.freebsd.org (Postfix) with ESMTP id 0541037B400 for ; Mon, 11 Dec 2000 14:29:52 -0800 (PST) Received: from fitz (root@localhost [127.0.0.1]) by shell6.ba.best.com (8.9.3/8.9.2/best.sh) with SMTP id OAA05107 for ; Mon, 11 Dec 2000 14:29:19 -0800 (PST) Message-ID: <001101c063c1$d2c46c60$040ca8c0@fitz> From: "John Fitzgibbon" To: Subject: Re: Etherboot 4.6.1 and FreeBSD 4.2 Release Date: Mon, 11 Dec 2000 14:29:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org For the benefit of fellow-sufferers: I figured it out. It was a plain old DOS problem rather than Etherboot/FreeBSD. I took the following lines out of my boot floppy's config.sys: device=himem.sys /testmem:off dos=high,umb stacks=9,256 ... and the kernel boots fine. Now I just need to get my conf files sorted.... ----- Original Message ----- From: "John Fitzgibbon" To: Sent: Sunday, December 10, 2000 7:11 PM Subject: Etherboot 4.6.1 and FreeBSD 4.2 Release > Anyone know if this combination works? > > I'm trying to use Etherboot 4.6.1's ne.com, (vanilla compile from the ports > collection), to diskless boot a 4.2 Release kernel. > > On the client, ne.com recognizes the kernel as FreeBSD/ELF and loads it from > the server. However, on switching to the kernel I immediately get the > following: > > Fatal trap 12: page fault while in vm86 mode... > fault code = user read, page not present... > panic page fault > > ... and I'm hosed. > > The kernel is compiled with the BOOTP options, (but it looks like its not > even loaded properly). > > Any suggestions/alternatives would be appreciated. > Cheers. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 11 19:50:13 2000 From owner-freebsd-net@FreeBSD.ORG Mon Dec 11 19:50:10 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from alpo.whistle.com (s206m1.whistle.com [207.76.206.1]) by hub.freebsd.org (Postfix) with ESMTP id 7BD8037B69C for ; Mon, 11 Dec 2000 19:50:03 -0800 (PST) Received: from whistle.com (crab.whistle.com [207.76.205.112]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id TAA79008; Mon, 11 Dec 2000 19:48:31 -0800 (PST) Received: (from ambrisko@localhost) by whistle.com (8.9.3/8.9.1) id TAA24198; Mon, 11 Dec 2000 19:48:21 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200012120348.TAA24198@whistle.com> Subject: Re: Etherboot 4.6.1 and FreeBSD 4.2 Release In-Reply-To: <001101c063c1$d2c46c60$040ca8c0@fitz> from John Fitzgibbon at "Dec 11, 2000 02:29:25 pm" To: John Fitzgibbon Date: Mon, 11 Dec 2000 19:48:20 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John Fitzgibbon writes: | For the benefit of fellow-sufferers: | | I figured it out. It was a plain old DOS problem rather than | Etherboot/FreeBSD. | | I took the following lines out of my boot floppy's config.sys: | | device=himem.sys /testmem:off | dos=high,umb | stacks=9,256 | | ... and the kernel boots fine. | | Now I just need to get my conf files sorted.... | | ----- Original Message ----- | From: "John Fitzgibbon" | | > Anyone know if this combination works? | > | > I'm trying to use Etherboot 4.6.1's ne.com, (vanilla compile from the | ports | > collection), to diskless boot a 4.2 Release kernel. | > | > On the client, ne.com recognizes the kernel as FreeBSD/ELF and loads it | from | > the server. However, on switching to the kernel I immediately get the | > following: | > | > Fatal trap 12: page fault while in vm86 mode... | > fault code = user read, page not present... | > panic page fault | > | > ... and I'm hosed. | > | > The kernel is compiled with the BOOTP options, (but it looks like its not | > even loaded properly). | > | > Any suggestions/alternatives would be appreciated. FYI, you can make a bootable floppy without the need for DOS via cd in work/etherboot/src and type gmake bin32/.fd0 That's what I usually do. Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 11 23:10:26 2000 From owner-freebsd-net@FreeBSD.ORG Mon Dec 11 23:10:23 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from unity.copyleft.no (unity.copyleft.no [212.71.72.23]) by hub.freebsd.org (Postfix) with ESMTP id 9254337B404 for ; Mon, 11 Dec 2000 23:10:22 -0800 (PST) Received: from martin by unity.copyleft.no with local (Exim 3.03 #1) id 145jZo-0005u2-00 for freebsd-net@freebsd.org; Tue, 12 Dec 2000 08:10:16 +0100 Date: Tue, 12 Dec 2000 08:10:16 +0100 From: Martin Eggen To: freebsd-net@freebsd.org Subject: ipfilter _and_ ipfirewall? Message-ID: <20001212081016.A22602@unity.copyleft.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: "Martin Eggen,Copyleft Software,901 17 341" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Would having the following in a kernel config work? options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options DUMMYNET options IPFILTER That is, to use ipfw exclusively for bandwidth limiting with dummynet, and ipfilter for packet filtering? I seem to recall that I've read a description of this, but came out empty when searching for anything regarding the topic. What path would packets go through the system with such a setup? Will this work, or should I use ALTQ for traffic shaping instead when filtering with IPFILTER? -- Martin Eggen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 11 23:39:25 2000 From owner-freebsd-net@FreeBSD.ORG Mon Dec 11 23:39:22 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 389CF37B400 for ; Mon, 11 Dec 2000 23:36:11 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 145k2V-0000FX-00; Tue, 12 Dec 2000 00:39:55 -0700 Sender: wes@FreeBSD.ORG Message-ID: <3A35D64A.D85D863C@softweyr.com> Date: Tue, 12 Dec 2000 00:39:54 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Michael Yeung Cc: net@FreeBSD.ORG Subject: Re: IP aliases and TCP socket References: <20001211191746.25563.qmail@web4903.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Michael Yeung wrote: > > Hi, > I have a few of questions and would greatly > appreciate for some advise. > > 1) What I want to do is to create an application that > can receive packets destined to two IP addresses from > different subnet/network. Essentially have a host > sitting at the broader of two networks. I noticed IP > aliases restrict the alias IP address to be in the > same subnet/network as the primary IP address. Is > that a true restriction? If so, any advise on > alternative to IP alias? Use two physical interfaces? You have two different networks on the same wire? Ugh. > 2) Assume IP aliases works for my needs as stated in > question1. When I send a packet out over a TCP socket > connection, how can I specify which address to be used > as the source IP address (i.e. primary or alias > address)? By specifying the IP address that you bind the socket to. In other words, you need to completely fill in the AF_INET sockaddr in the bind call, rather than allowing the default all-zeroes address, which means "take any old address that fits." > 3) Assume I can use IP aliases technique to receive > packet destined to different IP addresses in the same > application. If I am to use a TCP socket to retrieve > the packet, how can I tell which IP address what the > packet destined to (i.e. the primary or alias > address)? Would packets for all addresses goes to the > same socket or would it be through multiple sockets? You would want to open a socket per address, by specifying the address as I outline above. You will know the packet was destined for the address you bound the socket to, or it wouldn't arrive on that socket. > 4) Is there direct API calls to the TCP/UDP for > connection creation, sending and receiving? Or do I > have to go thru the socket interface. Are they > tcp_open, udp_open, tcp_send, udp_send, tcp_receive > and udp_receive? Where can I find these APIs and > their function prototypes? I have no idea what tcp_* and udp_* are. The direct API calls ARE the sockets interface. In particular, see the following man pages: socket(2), bind(2), getsockname(2), getpeername(2), listen(2), accept(2), read(2), write(2), send(2), recv(2) and a good book on UNIX network programming. "UNIX Network Programming, Volume 1: Networking APIs" by W. Richard Stevens ISBN: 013490012X would be the canonical choice. (My copy of Stevens is so old it came in ONE volume. We're going to miss him when it comes time to teach people IPv6 programming from the ground up. Sigh. RIP WRS.) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 1:44:34 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 01:44:32 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 52D8E37B400; Tue, 12 Dec 2000 01:44:32 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBC9iUq03639; Tue, 12 Dec 2000 01:44:30 -0800 (PST) Date: Tue, 12 Dec 2000 01:44:30 -0800 From: Alfred Perlstein To: Bosko Milekic Cc: net@FreeBSD.ORG, jhb@FreeBSD.ORG, jasone@FreeBSD.ORG Subject: MEXT_IS_REF broken. Message-ID: <20001212014429.Y16205@fw.wintelcom.net> References: <20001211014837.W16205@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bmilekic@technokratis.com on Mon, Dec 11, 2000 at 12:44:55PM -0500 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org grr... considering this: #define MEXT_IS_REF(m) ((m)->m_ext.ref_cnt->refcnt > 1) #define MEXT_REM_REF(m) do { \ KASSERT((m)->m_ext.ref_cnt->refcnt > 0, ("m_ext refcnt < 0")); \ atomic_subtract_long(&((m)->m_ext.ref_cnt->refcnt), 1); \ } while(0) this: #define MEXTFREE(m) do { \ struct mbuf *_mmm = (m); \ \ if (MEXT_IS_REF(_mmm)) \ MEXT_REM_REF(_mmm); \ is not mpsafe. we _NEED_ some type that allows atomic dec and test for 0. thanks, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 1:51: 4 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 01:51:02 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id F27D137B400; Tue, 12 Dec 2000 01:51:01 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBC9p0Q03858; Tue, 12 Dec 2000 01:51:00 -0800 (PST) Date: Tue, 12 Dec 2000 01:51:00 -0800 From: Alfred Perlstein To: Bosko Milekic Cc: net@FreeBSD.ORG, jhb@FreeBSD.ORG, jasone@FreeBSD.ORG Subject: Re: MEXT_IS_REF broken. Message-ID: <20001212015059.Z16205@fw.wintelcom.net> References: <20001211014837.W16205@fw.wintelcom.net> <20001212014429.Y16205@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001212014429.Y16205@fw.wintelcom.net>; from bright@wintelcom.net on Tue, Dec 12, 2000 at 01:44:30AM -0800 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Alfred Perlstein [001212 01:44] wrote: > grr... > > considering this: > > #define MEXT_IS_REF(m) ((m)->m_ext.ref_cnt->refcnt > 1) > > #define MEXT_REM_REF(m) do { \ > KASSERT((m)->m_ext.ref_cnt->refcnt > 0, ("m_ext refcnt < 0")); \ > atomic_subtract_long(&((m)->m_ext.ref_cnt->refcnt), 1); \ > } while(0) > > this: > > #define MEXTFREE(m) do { \ > struct mbuf *_mmm = (m); \ > \ > if (MEXT_IS_REF(_mmm)) \ > MEXT_REM_REF(_mmm); \ > > > is not mpsafe. we _NEED_ some type that allows atomic dec and test > for 0. Sorry, I didn't explain why this is broken, it looks safe because if it's 1 then only "we" reference it. This is incorrect: (m)->m_ext.ref_cnt->refcnt == 2 thread a thread b if (MEXT_IS_REF(m)) if (MEXT_IS_REF(m)) MEXT_REM_REF(m); MEXT_REM_REF(m); now... (m)->m_ext.ref_cnt->refcnt == 0. oops, now the destructor never gets called and we just leaked a mbuf cluster. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 3:39:37 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 03:39:34 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 7382D37B400 for ; Tue, 12 Dec 2000 03:39:34 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.15 #3) id 145nmH-000GXC-00; Tue, 12 Dec 2000 11:39:25 +0000 Date: Tue, 12 Dec 2000 11:39:25 +0000 From: Tony Finch To: Michael Yeung Cc: net@FreeBSD.ORG Subject: Re: IP aliases and TCP socket Message-ID: <20001212113925.M76746@hand.dotat.at> References: <20001211191746.25563.qmail@web4903.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20001211191746.25563.qmail@web4903.mail.yahoo.com> Organization: Covalent Technologies, Inc Sender: fanf@dotat.at Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Michael Yeung wrote: > >I noticed IP aliases restrict the alias IP address to be in the same >subnet/network as the primary IP address. Is that a true restriction? No. You configure aliases exactly as you would the primary address on an interface without restriction, except that aliases within the same network as an address previously added to the interface use a netmask of -1. >2) Assume IP aliases works for my needs as stated in question1. When >I send a packet out over a TCP socket connection, how can I specify >which address to be used as the source IP address (i.e. primary or >alias address)? bind(2) your socket to that address. >3) Assume I can use IP aliases technique to receive packet destined >to different IP addresses in the same application. If I am to use a >TCP socket to retrieve the packet, how can I tell which IP address >what the packet destined to (i.e. the primary or alias address)? getsockname(2) >Would packets for all addresses goes to the same socket or would it >be through multiple sockets? If you don't bind the listening socket to a specific IP address then the former, else the latter. >4) Is there direct API calls to the TCP/UDP for connection creation, >sending and receiving? Or do I have to go thru the socket interface. The socket interface is the most direct API there is (in userland). I suggest you get a copy of Stevens "Unix Network Programming". "TCP/IP Illustrated" and "Advanced Programming in the Unix Environment" are also good investments. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at "You realize there's a government directive stating that there is no such thing as a flying saucer?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 4:24:49 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 04:24:48 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id C5DF337B400; Tue, 12 Dec 2000 04:24:47 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBCCOlh07432; Tue, 12 Dec 2000 04:24:47 -0800 (PST) Date: Tue, 12 Dec 2000 04:24:47 -0800 From: Alfred Perlstein To: net@freebsd.org Cc: bmilekic@freebsd.org Subject: need mbuf generic free() hook Message-ID: <20001212042447.E16205@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: bright@fw.wintelcom.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ok, so I'm trying to rid FreeBSD of the unp_gc() junk in uipc_usrreq.c I just realized why I'm leaking file descriptors: Only mbufs with external storage can have a 'free' function, the problem is that for the most part when passing a single fd I'm only using a single mbuf to pass my data around, my ext_free routine is probably never called, and on top of that I'm probably corrupting my mbuf by using it when I shouldn't be. This is terrible, what should be a simple free() hook is now my worst nightmare. A couple of options come to mind: a) always have a free hook, the extra if (m->m_freehook != NULL) check can't be that expensive. b) a macro to make an mbuf into an mbuf cluster that points to itself, it should check to see if it has enough room to shuffle the data and return an error if it can't accomidate both the data and the expanded mbug header. I like 'a' but would be willing to deal with 'b' as we've never had a need for this, although that would mean copying about the size of an mbuf in the worst case when a subsystem needs this facility. Suggestions? Comments? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 7:50: 3 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 07:49:57 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id B706537B400; Tue, 12 Dec 2000 07:49:56 -0800 (PST) Received: from luanda-36.budapest.interware.hu ([195.70.51.36] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 145rgX-0004OU-00; Tue, 12 Dec 2000 16:49:45 +0100 Sender: julian@FreeBSD.ORG Message-ID: <3A36215A.712AE09A@elischer.org> Date: Tue, 12 Dec 2000 05:00:10 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Alfred Perlstein Cc: net@freebsd.org, bmilekic@freebsd.org Subject: Re: need mbuf generic free() hook References: <20001212042447.E16205@fw.wintelcom.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alfred Perlstein wrote: > > Ok, so I'm trying to rid FreeBSD of the unp_gc() junk in uipc_usrreq.c > I just realized why I'm leaking file descriptors: > > Only mbufs with external storage can have a 'free' function, the > problem is that for the most part when passing a single fd I'm only > using a single mbuf to pass my data around, my ext_free routine is > probably never called, and on top of that I'm probably corrupting > my mbuf by using it when I shouldn't be. > > This is terrible, what should be a simple free() hook is now my > worst nightmare. A couple of options come to mind: > > a) always have a free hook, the extra if (m->m_freehook != NULL) > check can't be that expensive. > b) a macro to make an mbuf into an mbuf cluster that points to itself, > it should check to see if it has enough room to shuffle the data > and return an error if it can't accomidate both the data and the > expanded mbug header. > > I like 'a' but would be willing to deal with 'b' as we've never > had a need for this, although that would mean copying about the > size of an mbuf in the worst case when a subsystem needs this > facility. The external object in the mbuf can be virtual. You can Say it is external and point the pointers to a static place and set the mbuf to b ereadonly and have an m_len of 0 Then your free routine woild be called, but you would not need to alocate a cluster for it. > > Suggestions? Comments? > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 8:10:59 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 08:10:57 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from smtp2.szonline.net (ns.szonline.net [202.96.154.15]) by hub.freebsd.org (Postfix) with ESMTP id CB3EE37B400 for ; Tue, 12 Dec 2000 08:10:55 -0800 (PST) Received: from server ([202.104.116.239]) by smtp2.szonline.net (8.10.1/8.10.1) with SMTP id eBCGCAc25067 for ; Wed, 13 Dec 2000 00:12:14 +0800 (CST) Message-ID: <001201c06455$8d5c0630$ef7468ca@server> Reply-To: "John Wu" From: "John Wu" To: Subject: auth c409e3fe subscribe freebsd-net johnwu2000@371.net Date: Wed, 13 Dec 2000 00:06:07 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C06498.7D97A270" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C06498.7D97A270 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 YXV0aCBjNDA5ZTNmZSBzdWJzY3JpYmUgZnJlZWJzZC1uZXQgam9obnd1MjAwMEAzNzEubmV0DQoN Cg0K ------=_NextPart_000_000F_01C06498.7D97A270 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yOTIwLjAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E WSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5hdXRoIGM0MDllM2ZlIHN1YnNj cmliZSBmcmVlYnNkLW5ldCA8QSANCmhyZWY9Im1haWx0bzpqb2hud3UyMDAwQDM3MS5uZXQiPmpv aG53dTIwMDBAMzcxLm5ldDwvQT48QlI+PEJSPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_000F_01C06498.7D97A270-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 8:39:42 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 08:39:37 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id CD2F937B402; Tue, 12 Dec 2000 08:39:35 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eBCGdME87547; Tue, 12 Dec 2000 08:39:22 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20001212014429.Y16205@fw.wintelcom.net> Date: Tue, 12 Dec 2000 08:39:27 -0800 (PST) From: John Baldwin To: Alfred Perlstein Subject: RE: MEXT_IS_REF broken. Cc: jasone@FreeBSD.org, net@FreeBSD.org, Bosko Milekic Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 12-Dec-00 Alfred Perlstein wrote: > grr... > > considering this: > >#define MEXT_IS_REF(m) ((m)->m_ext.ref_cnt->refcnt > 1) > >#define MEXT_REM_REF(m) do { \ > KASSERT((m)->m_ext.ref_cnt->refcnt > 0, ("m_ext refcnt < 0")); \ > atomic_subtract_long(&((m)->m_ext.ref_cnt->refcnt), 1); \ > } while(0) > > this: > >#define MEXTFREE(m) do { \ > struct mbuf *_mmm = (m); \ > \ > if (MEXT_IS_REF(_mmm)) \ > MEXT_REM_REF(_mmm); \ > > > is not mpsafe. we _NEED_ some type that allows atomic dec and test > for 0. http://www.FreeBSD.org/~jhb/patches/refcount.patch > thanks, > -Alfred -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 11:48:13 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 11:48:11 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 478BB37B400; Tue, 12 Dec 2000 11:48:11 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBCJmBf20037; Tue, 12 Dec 2000 11:48:11 -0800 (PST) Date: Tue, 12 Dec 2000 11:48:11 -0800 From: Alfred Perlstein To: John Baldwin Cc: jasone@FreeBSD.org, net@FreeBSD.org, Bosko Milekic Subject: Re: MEXT_IS_REF broken. Message-ID: <20001212114810.H16205@fw.wintelcom.net> References: <20001212014429.Y16205@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Tue, Dec 12, 2000 at 08:39:27AM -0800 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * John Baldwin [001212 08:39] wrote: > > On 12-Dec-00 Alfred Perlstein wrote: > > grr... > > > > considering this: > > > >#define MEXT_IS_REF(m) ((m)->m_ext.ref_cnt->refcnt > 1) > > > >#define MEXT_REM_REF(m) do { \ > > KASSERT((m)->m_ext.ref_cnt->refcnt > 0, ("m_ext refcnt < 0")); \ > > atomic_subtract_long(&((m)->m_ext.ref_cnt->refcnt), 1); \ > > } while(0) > > > > this: > > > >#define MEXTFREE(m) do { \ > > struct mbuf *_mmm = (m); \ > > \ > > if (MEXT_IS_REF(_mmm)) \ > > MEXT_REM_REF(_mmm); \ > > > > > > is not mpsafe. we _NEED_ some type that allows atomic dec and test > > for 0. > > http://www.FreeBSD.org/~jhb/patches/refcount.patch You do have a commit bit if I'm not mistaken. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 12:11:14 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 12:11:12 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id EB99037B400; Tue, 12 Dec 2000 12:11:11 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eBCKAwE95228; Tue, 12 Dec 2000 12:10:58 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20001212114810.H16205@fw.wintelcom.net> Date: Tue, 12 Dec 2000 12:11:03 -0800 (PST) From: John Baldwin To: Alfred Perlstein Subject: Re: MEXT_IS_REF broken. Cc: Bosko Milekic , net@FreeBSD.org, jasone@FreeBSD.org Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 12-Dec-00 Alfred Perlstein wrote: > * John Baldwin [001212 08:39] wrote: >> >> On 12-Dec-00 Alfred Perlstein wrote: >> > grr... >> > >> > considering this: >> > >> >#define MEXT_IS_REF(m) ((m)->m_ext.ref_cnt->refcnt > 1) >> > >> >#define MEXT_REM_REF(m) do { \ >> > KASSERT((m)->m_ext.ref_cnt->refcnt > 0, ("m_ext refcnt < 0")); \ >> > atomic_subtract_long(&((m)->m_ext.ref_cnt->refcnt), 1); \ >> > } while(0) >> > >> > this: >> > >> >#define MEXTFREE(m) do { \ >> > struct mbuf *_mmm = (m); \ >> > \ >> > if (MEXT_IS_REF(_mmm)) \ >> > MEXT_REM_REF(_mmm); \ >> > >> > >> > is not mpsafe. we _NEED_ some type that allows atomic dec and test >> > for 0. >> >> http://www.FreeBSD.org/~jhb/patches/refcount.patch > > You do have a commit bit if I'm not mistaken. :) I would like some feedback on it. :) I guess I should really send it off to -arch for a bikeshed slugfest. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 13:34:25 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 13:34:24 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id 2D22437B400 for ; Tue, 12 Dec 2000 13:34:24 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1098) id 2C6312B2B9; Tue, 12 Dec 2000 15:34:23 -0600 (CST) Date: Tue, 12 Dec 2000 15:34:23 -0600 From: Bill Fumerola To: Martin Eggen Cc: freebsd-net@freebsd.org Subject: Re: ipfilter _and_ ipfirewall? Message-ID: <20001212153422.A72273@elvis.mu.org> References: <20001212081016.A22602@unity.copyleft.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001212081016.A22602@unity.copyleft.no>; from martin@copyleft.no on Tue, Dec 12, 2000 at 08:10:16AM +0100 X-Operating-System: FreeBSD 4.2-FEARSOME-20001103 i386 Sender: billf@elvis.mu.org Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Dec 12, 2000 at 08:10:16AM +0100, Martin Eggen wrote: > Would having the following in a kernel config work? > > options IPFIREWALL > options IPFIREWALL_DEFAULT_TO_ACCEPT > options DUMMYNET > options IPFILTER > > That is, to use ipfw exclusively for bandwidth limiting with dummynet, and > ipfilter for packet filtering? > I seem to recall that I've read a description of this, but came out empty > when searching for anything regarding the topic. As answered multiple times on multiple lists: yes. -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 14: 9:30 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 14:09:26 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 4F53537B400; Tue, 12 Dec 2000 14:09:25 -0800 (PST) Received: from bissau-13.budapest.interware.hu ([195.70.53.141] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 145xbd-0004eL-00; Tue, 12 Dec 2000 23:09:12 +0100 Sender: julian@FreeBSD.ORG Message-ID: <3A36A1D8.8297C7B8@elischer.org> Date: Tue, 12 Dec 2000 14:08:24 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: John Baldwin Cc: Alfred Perlstein , jasone@FreeBSD.org, net@FreeBSD.org, Bosko Milekic Subject: Re: MEXT_IS_REF broken. References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John Baldwin wrote: > > On 12-Dec-00 Alfred Perlstein wrote: > > grr... > > > > considering this: > > > >#define MEXT_IS_REF(m) ((m)->m_ext.ref_cnt->refcnt > 1) > > > >#define MEXT_REM_REF(m) do { \ > > KASSERT((m)->m_ext.ref_cnt->refcnt > 0, ("m_ext refcnt < 0")); \ > > atomic_subtract_long(&((m)->m_ext.ref_cnt->refcnt), 1); \ > > } while(0) > > > > this: > > > >#define MEXTFREE(m) do { \ > > struct mbuf *_mmm = (m); \ > > \ > > if (MEXT_IS_REF(_mmm)) \ > > MEXT_REM_REF(_mmm); \ > > > > > > is not mpsafe. we _NEED_ some type that allows atomic dec and test > > for 0. > > http://www.FreeBSD.org/~jhb/patches/refcount.patch this is great but if I understand it, there is a hole... the operations are atomic, but if teh count is 1 and the release and aquire are called at around the same time, then thre are two possibilities.. the value goes 1 -> 2 -> 1 (this is ok) the value goes 1 -> 0 -> 1 ( this is NOT ok) the aquire calls atomic_add_acq_int(count, 1); which by my reading of the code last week, compiles down to lock ; addl (mumble) if the value that the aquire finds is 0 then it should fail and return without incrementing.. the returned value of 0 for the other processor will cause it to garbage collect the object in a very sort amount of time so trying to use it is a bad idea. Am I missing something here? Hopefully there si some higher level lock or something that stops you from trying to reference an object that is having its last reference removed (otherwise how did you find it?) but never-the less, it's an issue to look at. > > > thanks, > > -Alfred > > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 14:32:36 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 14:32:33 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 0A4F337B404 for ; Tue, 12 Dec 2000 14:32:32 -0800 (PST) Received: (qmail 31281 invoked by uid 1142); 12 Dec 2000 22:32:30 -0000 Date: 12 Dec 2000 14:32:30 -0800 Date: Tue, 12 Dec 2000 14:32:15 -0800 From: Jason Evans To: Alfred Perlstein Cc: Bosko Milekic , net@FreeBSD.ORG, jhb@FreeBSD.ORG Subject: Re: MEXT_IS_REF broken. Message-ID: <20001212143214.H2312@canonware.com> References: <20001211014837.W16205@fw.wintelcom.net> <20001212014429.Y16205@fw.wintelcom.net> <20001212015059.Z16205@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001212015059.Z16205@fw.wintelcom.net>; from bright@wintelcom.net on Tue, Dec 12, 2000 at 01:51:00AM -0800 Sender: jasone@magnesium.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Dec 12, 2000 at 01:51:00AM -0800, Alfred Perlstein wrote: > * Alfred Perlstein [001212 01:44] wrote: > > grr... > > > > considering this: > > > > #define MEXT_IS_REF(m) ((m)->m_ext.ref_cnt->refcnt > 1) > > > > #define MEXT_REM_REF(m) do { \ > > KASSERT((m)->m_ext.ref_cnt->refcnt > 0, ("m_ext refcnt < 0")); \ > > atomic_subtract_long(&((m)->m_ext.ref_cnt->refcnt), 1); \ > > } while(0) > > > > this: > > > > #define MEXTFREE(m) do { \ > > struct mbuf *_mmm = (m); \ > > \ > > if (MEXT_IS_REF(_mmm)) \ > > MEXT_REM_REF(_mmm); \ > > > > > > is not mpsafe. we _NEED_ some type that allows atomic dec and test > > for 0. > > Sorry, I didn't explain why this is broken, it looks safe because > if it's 1 then only "we" reference it. This is incorrect: > > (m)->m_ext.ref_cnt->refcnt == 2 > > thread a thread b > > if (MEXT_IS_REF(m)) > if (MEXT_IS_REF(m)) > MEXT_REM_REF(m); > MEXT_REM_REF(m); > > now... (m)->m_ext.ref_cnt->refcnt == 0. > > oops, now the destructor never gets called and we just leaked a > mbuf cluster. The current macro: --------------------------------------------------------------------------- #define MEXTFREE(m) do { \ struct mbuf *_mmm = (m); \ \ if (MEXT_IS_REF(_mmm)) \ MEXT_REM_REF(_mmm); \ else if (_mmm->m_ext.ext_type != EXT_CLUSTER) { \ (*(_mmm->m_ext.ext_free))(_mmm->m_ext.ext_buf, \ _mmm->m_ext.ext_args); \ _MEXT_DEALLOC_CNT(_mmm->m_ext.ref_cnt); \ } else { \ _MCLFREE(_mmm->m_ext.ext_buf); \ _MEXT_DEALLOC_CNT(_mmm->m_ext.ref_cnt); \ } \ _mmm->m_flags &= ~M_EXT; \ } while (0) --------------------------------------------------------------------------- A safe version: --------------------------------------------------------------------------- #define MEXTFREE(m) do { \ struct mbuf *_mmm = (m); \ \ MEXT_REM_REF(_mmm); \ if (!atomic_cmpset_long(&_mmm->m_ext.ref_cnt->refcnt, 0, 1)) { \ /* \ * Do not free; there are still references, or another \ * thread is freeing. \ */ \ } else if (_mmm->m_ext.ext_type != EXT_CLUSTER) { \ (*(_mmm->m_ext.ext_free))(_mmm->m_ext.ext_buf, \ _mmm->m_ext.ext_args); \ _MEXT_DEALLOC_CNT(_mmm->m_ext.ref_cnt); \ } else { \ _MCLFREE(_mmm->m_ext.ext_buf); \ _MEXT_DEALLOC_CNT(_mmm->m_ext.ref_cnt); \ } \ _mmm->m_flags &= ~M_EXT; \ } while (0) --------------------------------------------------------------------------- What this does is have all threads unconditionally atomically decrement. Then, in order to determine whether to clean up, the threads to an atomic compare and set on the refcount, so that if it is 0, only one thread manages to modify the refcount, which then signifies that it will do the cleanup. It looks like this should work to me, without the need for an atomic refcount type. Yes, it requires two atomic operations, but it avoids the need for a mutex, which seems to be your main concern. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 15:17:39 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 15:17:34 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id C604637B402 for ; Tue, 12 Dec 2000 15:17:33 -0800 (PST) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eBCNHLE01735; Tue, 12 Dec 2000 15:17:21 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.0) id eBCNGZf20964; Tue, 12 Dec 2000 15:16:35 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20001212143214.H2312@canonware.com> Date: Tue, 12 Dec 2000 15:16:35 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: Jason Evans Subject: Re: MEXT_IS_REF broken. Cc: net@FreeBSD.ORG, Bosko Milekic , Alfred Perlstein Sender: jhb@foo.osd.bsdi.com Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 12-Dec-00 Jason Evans wrote: > On Tue, Dec 12, 2000 at 01:51:00AM -0800, Alfred Perlstein wrote: >> * Alfred Perlstein [001212 01:44] wrote: >> > grr... >> > >> > considering this: >> > >> > #define MEXT_IS_REF(m) ((m)->m_ext.ref_cnt->refcnt > 1) >> > >> > #define MEXT_REM_REF(m) do { \ >> > KASSERT((m)->m_ext.ref_cnt->refcnt > 0, ("m_ext refcnt < 0")); \ >> > atomic_subtract_long(&((m)->m_ext.ref_cnt->refcnt), 1); \ >> > } while(0) >> > >> > this: >> > >> > #define MEXTFREE(m) do { \ >> > struct mbuf *_mmm = (m); \ >> > \ >> > if (MEXT_IS_REF(_mmm)) \ >> > MEXT_REM_REF(_mmm); \ >> > >> > >> > is not mpsafe. we _NEED_ some type that allows atomic dec and test >> > for 0. >> >> Sorry, I didn't explain why this is broken, it looks safe because >> if it's 1 then only "we" reference it. This is incorrect: >> >> (m)->m_ext.ref_cnt->refcnt == 2 >> >> thread a thread b >> >> if (MEXT_IS_REF(m)) >> if (MEXT_IS_REF(m)) >> MEXT_REM_REF(m); >> MEXT_REM_REF(m); >> >> now... (m)->m_ext.ref_cnt->refcnt == 0. >> >> oops, now the destructor never gets called and we just leaked a >> mbuf cluster. > > The current macro: > --------------------------------------------------------------------------- >#define MEXTFREE(m) do { \ > struct mbuf *_mmm = (m); \ > \ > if (MEXT_IS_REF(_mmm)) \ > MEXT_REM_REF(_mmm); \ > else if (_mmm->m_ext.ext_type != EXT_CLUSTER) { \ > (*(_mmm->m_ext.ext_free))(_mmm->m_ext.ext_buf, \ > _mmm->m_ext.ext_args); \ > _MEXT_DEALLOC_CNT(_mmm->m_ext.ref_cnt); \ > } else { \ > _MCLFREE(_mmm->m_ext.ext_buf); \ > _MEXT_DEALLOC_CNT(_mmm->m_ext.ref_cnt); \ > } \ > _mmm->m_flags &= ~M_EXT; \ > } while (0) > --------------------------------------------------------------------------- > > A safe version: > --------------------------------------------------------------------------- >#define MEXTFREE(m) do { \ > struct mbuf *_mmm = (m); \ > \ > MEXT_REM_REF(_mmm); \ > if (!atomic_cmpset_long(&_mmm->m_ext.ref_cnt->refcnt, 0, 1)) { \ > /* \ > * Do not free; there are still references, or another \ > * thread is freeing. \ > */ \ > } else if (_mmm->m_ext.ext_type != EXT_CLUSTER) { \ > (*(_mmm->m_ext.ext_free))(_mmm->m_ext.ext_buf, \ > _mmm->m_ext.ext_args); \ > _MEXT_DEALLOC_CNT(_mmm->m_ext.ref_cnt); \ > } else { \ > _MCLFREE(_mmm->m_ext.ext_buf); \ > _MEXT_DEALLOC_CNT(_mmm->m_ext.ref_cnt); \ > } \ > _mmm->m_flags &= ~M_EXT; \ > } while (0) > --------------------------------------------------------------------------- > > What this does is have all threads unconditionally atomically decrement. > Then, in order to determine whether to clean up, the threads to an atomic > compare and set on the refcount, so that if it is 0, only one thread > manages to modify the refcount, which then signifies that it will do the > cleanup. > > It looks like this should work to me, without the need for an atomic > refcount type. Yes, it requires two atomic operations, but it avoids the > need for a mutex, which seems to be your main concern. Since two atomic operations are all that are done during a mutex acquire and release, and since at least in teh x86 case the major cost _is_ the locked bus cycles for atomic operations, using two operations is probably just as expensive as using a mutex. What is wrong with having an encapsulated type so that you can do: if (refcount_release(&_mmm->m_ext.ref_cnt)) { /* * free object */ } You can then implement reference counts however you wish. Not mention that atomic_cmpset_long() may be very expensive on some archs. > Jason -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 15:19:58 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 15:19:55 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 8A7A837B400; Tue, 12 Dec 2000 15:19:55 -0800 (PST) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eBCNJjE01820; Tue, 12 Dec 2000 15:19:45 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.0) id eBCNIx120971; Tue, 12 Dec 2000 15:18:59 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3A36A1D8.8297C7B8@elischer.org> Date: Tue, 12 Dec 2000 15:18:59 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: Julian Elischer Subject: Re: MEXT_IS_REF broken. Cc: Bosko Milekic , net@FreeBSD.ORG, jasone@FreeBSD.ORG, Alfred Perlstein Sender: jhb@foo.osd.bsdi.com Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 12-Dec-00 Julian Elischer wrote: > John Baldwin wrote: >> >> On 12-Dec-00 Alfred Perlstein wrote: >> > grr... >> > >> > considering this: >> > >> >#define MEXT_IS_REF(m) ((m)->m_ext.ref_cnt->refcnt > 1) >> > >> >#define MEXT_REM_REF(m) do { \ >> > KASSERT((m)->m_ext.ref_cnt->refcnt > 0, ("m_ext refcnt < 0")); \ >> > atomic_subtract_long(&((m)->m_ext.ref_cnt->refcnt), 1); \ >> > } while(0) >> > >> > this: >> > >> >#define MEXTFREE(m) do { \ >> > struct mbuf *_mmm = (m); \ >> > \ >> > if (MEXT_IS_REF(_mmm)) \ >> > MEXT_REM_REF(_mmm); \ >> > >> > >> > is not mpsafe. we _NEED_ some type that allows atomic dec and test >> > for 0. >> >> http://www.FreeBSD.org/~jhb/patches/refcount.patch > > this is great but if I understand it, there is a hole... > the operations are atomic, but if teh count is 1 > and the release and aquire are called at around the same time, > then thre are two possibilities.. > the value goes 1 -> 2 -> 1 (this is ok) > the value goes 1 -> 0 -> 1 ( this is NOT ok) > the aquire calls atomic_add_acq_int(count, 1); > > which by my reading of the code last week, compiles down to > lock ; addl (mumble) > > if the value that the aquire finds is 0 then it should fail and return > without incrementing.. the returned value of 0 for the other processor > will cause it to garbage collect the object in a very sort amount of time > so trying to use it is a bad idea. > > > Am I missing something here? Yes, I think you are. A CPU can't magically obtain a reference to something in order to bump the refcount in the 1 -> 0 -> 1 case. If you aren't doing things with the object w/o holding a reference count first, then where will cpu B get the reference to know to do the refcount_acquire() from? -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 16: 7:35 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 16:07:33 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from web118.yahoomail.com (web118.mail.yahoo.com [205.180.60.99]) by hub.freebsd.org (Postfix) with SMTP id 406D637B400 for ; Tue, 12 Dec 2000 16:07:33 -0800 (PST) Received: (qmail 19865 invoked by uid 60001); 13 Dec 2000 00:07:33 -0000 Message-ID: <20001213000733.19864.qmail@web118.yahoomail.com> Received: from [24.190.253.123] by web118.yahoomail.com; Tue, 12 Dec 2000 16:07:32 PST Date: Tue, 12 Dec 2000 16:07:32 -0800 (PST) From: Holtor Subject: Packets Per Second To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello all, Does anyone know how many packets per second a box running freebsd 4.2-stable with 2 fast ethernet cards could push? It would be acting as a router/firewall. I know this depends on CPU, lets say its a PIII 850 with 128mb ram. If there is an equation to help figure it out I would love to know. TIA to anyone who replies. Holt PS. Please include my e-mail in all replies since i'm not on this list. __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 17:59:43 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 17:59:40 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 6CD0837B400; Tue, 12 Dec 2000 17:59:40 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBD1xb101940; Tue, 12 Dec 2000 17:59:37 -0800 (PST) Date: Tue, 12 Dec 2000 17:59:37 -0800 From: Alfred Perlstein To: Jason Evans Cc: Bosko Milekic , net@FreeBSD.ORG, jhb@FreeBSD.ORG Subject: Re: MEXT_IS_REF broken. Message-ID: <20001212175937.M16205@fw.wintelcom.net> References: <20001211014837.W16205@fw.wintelcom.net> <20001212014429.Y16205@fw.wintelcom.net> <20001212015059.Z16205@fw.wintelcom.net> <20001212143214.H2312@canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001212143214.H2312@canonware.com>; from jasone@canonware.com on Tue, Dec 12, 2000 at 02:32:15PM -0800 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Jason Evans [001212 14:32] wrote: > On Tue, Dec 12, 2000 at 01:51:00AM -0800, Alfred Perlstein wrote: > > A safe version: > --------------------------------------------------------------------------- > #define MEXTFREE(m) do { \ > struct mbuf *_mmm = (m); \ > \ > MEXT_REM_REF(_mmm); \ > if (!atomic_cmpset_long(&_mmm->m_ext.ref_cnt->refcnt, 0, 1)) { \ > /* \ > * Do not free; there are still references, or another \ > * thread is freeing. \ > */ \ > } else if (_mmm->m_ext.ext_type != EXT_CLUSTER) { \ > (*(_mmm->m_ext.ext_free))(_mmm->m_ext.ext_buf, \ > _mmm->m_ext.ext_args); \ > _MEXT_DEALLOC_CNT(_mmm->m_ext.ref_cnt); \ > } else { \ > _MCLFREE(_mmm->m_ext.ext_buf); \ > _MEXT_DEALLOC_CNT(_mmm->m_ext.ref_cnt); \ > } \ > _mmm->m_flags &= ~M_EXT; \ > } while (0) > --------------------------------------------------------------------------- > > What this does is have all threads unconditionally atomically decrement. > Then, in order to determine whether to clean up, the threads to an atomic > compare and set on the refcount, so that if it is 0, only one thread > manages to modify the refcount, which then signifies that it will do the > cleanup. > > It looks like this should work to me, without the need for an atomic > refcount type. Yes, it requires two atomic operations, but it avoids the > need for a mutex, which seems to be your main concern. You've just proved why we need atomic ops that aren't so clumsy. Your solution doesn't work, the code is broken. You can't use atomic_cmpset_long to do a counter like that, it's the same race, you're just seeing if it goes to zero, now if it doesn't how do you decrement it? Use atomic_subtract_long? no, same race as the old code. Now can you _please_ give John the go-ahead to commit this so I can fix it and use it whereever else it's needed? Actually, in truth I think you can get the code right like so: long x = _mmm->m_ext.ref_cnt->refcnt; while (!atomic_cmpset_long(&_mmm->m_ext.ref_cnt->refcnt, x - 1, x)) ; But that's just gross, expensive and shouldn't be needed. The reason why you need 'x' is that you can't do this: while (!atomic_cmpset_long(&_mmm->m_ext.ref_cnt->refcnt, _mmm->m_ext.ref_cnt->refcnt - 1, _mmm->m_ext.ref_cnt->refcnt)) ; Because you don't know if there's a race that may modify the value between pushing it on the stack as the second and third parameter. And since Chuck backs me up on this, can we consider this discussion over as soon as John commits his code? thanks, -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 18: 0:46 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 18:00:43 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 71E8D37B400; Tue, 12 Dec 2000 18:00:43 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBD20hr02079; Tue, 12 Dec 2000 18:00:43 -0800 (PST) Date: Tue, 12 Dec 2000 18:00:43 -0800 From: Alfred Perlstein To: John Baldwin Cc: Julian Elischer , Bosko Milekic , net@FreeBSD.ORG, jasone@FreeBSD.ORG Subject: Re: MEXT_IS_REF broken. Message-ID: <20001212180043.N16205@fw.wintelcom.net> References: <3A36A1D8.8297C7B8@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.ORG on Tue, Dec 12, 2000 at 03:18:59PM -0800 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * John Baldwin [001212 15:19] wrote: > > On 12-Dec-00 Julian Elischer wrote: > > John Baldwin wrote: > >> > >> On 12-Dec-00 Alfred Perlstein wrote: > >> > grr... > >> > > >> > considering this: > >> > > >> >#define MEXT_IS_REF(m) ((m)->m_ext.ref_cnt->refcnt > 1) > >> > > >> >#define MEXT_REM_REF(m) do { \ > >> > KASSERT((m)->m_ext.ref_cnt->refcnt > 0, ("m_ext refcnt < 0")); \ > >> > atomic_subtract_long(&((m)->m_ext.ref_cnt->refcnt), 1); \ > >> > } while(0) > >> > > >> > this: > >> > > >> >#define MEXTFREE(m) do { \ > >> > struct mbuf *_mmm = (m); \ > >> > \ > >> > if (MEXT_IS_REF(_mmm)) \ > >> > MEXT_REM_REF(_mmm); \ > >> > > >> > > >> > is not mpsafe. we _NEED_ some type that allows atomic dec and test > >> > for 0. > >> > >> http://www.FreeBSD.org/~jhb/patches/refcount.patch > > > > this is great but if I understand it, there is a hole... > > the operations are atomic, but if teh count is 1 > > and the release and aquire are called at around the same time, > > then thre are two possibilities.. > > the value goes 1 -> 2 -> 1 (this is ok) > > the value goes 1 -> 0 -> 1 ( this is NOT ok) > > the aquire calls atomic_add_acq_int(count, 1); > > > > which by my reading of the code last week, compiles down to > > lock ; addl (mumble) > > > > if the value that the aquire finds is 0 then it should fail and return > > without incrementing.. the returned value of 0 for the other processor > > will cause it to garbage collect the object in a very sort amount of time > > so trying to use it is a bad idea. > > > > > > Am I missing something here? > > Yes, I think you are. A CPU can't magically obtain a reference to something in > order to bump the refcount in the 1 -> 0 -> 1 case. If you aren't doing things > with the object w/o holding a reference count first, then where will cpu B get > the reference to know to do the refcount_acquire() from? You're correct, you need the higher level lock to do this operation. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 18:39:45 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 18:39:43 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 72B4F37B402 for ; Tue, 12 Dec 2000 18:39:42 -0800 (PST) Received: (qmail 38552 invoked by uid 1142); 13 Dec 2000 02:39:41 -0000 Date: 12 Dec 2000 18:39:41 -0800 Date: Tue, 12 Dec 2000 18:39:30 -0800 From: Jason Evans To: Alfred Perlstein Cc: Bosko Milekic , net@FreeBSD.ORG, jhb@FreeBSD.ORG Subject: Re: MEXT_IS_REF broken. Message-ID: <20001212183930.L2312@canonware.com> References: <20001211014837.W16205@fw.wintelcom.net> <20001212014429.Y16205@fw.wintelcom.net> <20001212015059.Z16205@fw.wintelcom.net> <20001212143214.H2312@canonware.com> <20001212175937.M16205@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001212175937.M16205@fw.wintelcom.net>; from bright@wintelcom.net on Tue, Dec 12, 2000 at 05:59:37PM -0800 Sender: jasone@magnesium.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Dec 12, 2000 at 05:59:37PM -0800, Alfred Perlstein wrote: > * Jason Evans [001212 14:32] wrote: > > A safe version: > > --------------------------------------------------------------------------- > > #define MEXTFREE(m) do { \ > > struct mbuf *_mmm = (m); \ > > \ > > MEXT_REM_REF(_mmm); \ > > if (!atomic_cmpset_long(&_mmm->m_ext.ref_cnt->refcnt, 0, 1)) { \ > > /* \ > > * Do not free; there are still references, or another \ > > * thread is freeing. \ > > */ \ > > } else if (_mmm->m_ext.ext_type != EXT_CLUSTER) { \ > > (*(_mmm->m_ext.ext_free))(_mmm->m_ext.ext_buf, \ > > _mmm->m_ext.ext_args); \ > > _MEXT_DEALLOC_CNT(_mmm->m_ext.ref_cnt); \ > > } else { \ > > _MCLFREE(_mmm->m_ext.ext_buf); \ > > _MEXT_DEALLOC_CNT(_mmm->m_ext.ref_cnt); \ > > } \ > > _mmm->m_flags &= ~M_EXT; \ > > } while (0) > > --------------------------------------------------------------------------- > > > > What this does is have all threads unconditionally atomically decrement. > > Then, in order to determine whether to clean up, the threads to an atomic > > compare and set on the refcount, so that if it is 0, only one thread > > manages to modify the refcount, which then signifies that it will do the > > cleanup. > > You've just proved why we need atomic ops that aren't so clumsy. > > Your solution doesn't work, the code is broken. > > You can't use atomic_cmpset_long to do a counter like that, it's > the same race, you're just seeing if it goes to zero, now if it > doesn't how do you decrement it? Use atomic_subtract_long? no, > same race as the old code. Please read my code and explanation again. You seem to have missed the order of arguments to atomic_cmpset_long(). The cmpset call detects whether the refcount is already 0, and only allows one thread to increment it; that thread then does the cleanup. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 18:43:38 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 18:43:36 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id 208DC37B400; Tue, 12 Dec 2000 18:43:36 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G5H00L9HJKGK8@field.videotron.net>; Tue, 12 Dec 2000 21:43:28 -0500 (EST) Date: Tue, 12 Dec 2000 21:44:38 -0500 (EST) From: Bosko Milekic Subject: Re: MEXT_IS_REF broken. In-reply-to: <20001212175937.M16205@fw.wintelcom.net> To: Alfred Perlstein Cc: Jason Evans , net@FreeBSD.ORG, jhb@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 12 Dec 2000, Alfred Perlstein wrote: [...] > And since Chuck backs me up on this, can we consider this discussion > over as soon as John commits his code? I think this is a valid point. This is not the first time the need for proper refcount "interface" arises, or at least the discussion of the need for it, and I would say that it is better to do this now than later. Clearly, the ref. count code in mbuf.h is suffering from a pretty nasty race. Even if we use the particularities of the mbuf cluster referencing system to fix it one way now, we're bound to encounter similar problems sooner or later. > thanks, > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." Cheers, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 18:50: 4 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 18:50:00 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 7EC6C37B400 for ; Tue, 12 Dec 2000 18:50:00 -0800 (PST) Received: (qmail 38915 invoked by uid 1142); 13 Dec 2000 02:49:59 -0000 Date: 12 Dec 2000 18:49:59 -0800 Date: Tue, 12 Dec 2000 18:49:38 -0800 From: Jason Evans To: Alfred Perlstein Cc: Bosko Milekic , net@FreeBSD.ORG, jhb@FreeBSD.ORG Subject: Re: MEXT_IS_REF broken. Message-ID: <20001212184938.N2312@canonware.com> References: <20001211014837.W16205@fw.wintelcom.net> <20001212014429.Y16205@fw.wintelcom.net> <20001212015059.Z16205@fw.wintelcom.net> <20001212143214.H2312@canonware.com> <20001212175937.M16205@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001212175937.M16205@fw.wintelcom.net>; from bright@wintelcom.net on Tue, Dec 12, 2000 at 05:59:37PM -0800 Sender: jasone@magnesium.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Dec 12, 2000 at 05:59:37PM -0800, Alfred Perlstein wrote: > And since Chuck backs me up on this, can we consider this discussion > over as soon as John commits his code? No. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 18:50:34 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 18:50:31 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 1838B37B400 for ; Tue, 12 Dec 2000 18:50:31 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id VAA55319; Tue, 12 Dec 2000 21:50:19 -0500 (EST) (envelope-from wollman) Date: Tue, 12 Dec 2000 21:50:19 -0500 (EST) From: Garrett Wollman Message-Id: <200012130250.VAA55319@khavrinen.lcs.mit.edu> To: Alfred Perlstein Cc: net@FreeBSD.ORG Subject: Re: MEXT_IS_REF broken. In-Reply-To: <20001212175937.M16205@fw.wintelcom.net> References: <20001211014837.W16205@fw.wintelcom.net> <20001212014429.Y16205@fw.wintelcom.net> <20001212015059.Z16205@fw.wintelcom.net> <20001212143214.H2312@canonware.com> <20001212175937.M16205@fw.wintelcom.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Actually, in truth I think you can get the code right like so: > long x = _mmm->m_ext.ref_cnt->refcnt; > while (!atomic_cmpset_long(&_mmm->m_ext.ref_cnt->refcnt, x - 1, x)) > ; Cool! You've just (almost) reinvented non-blocking parallel reference-counts. Of course, what you really need is: long atomic_decrement_long(long *where) { long oldval; do { oldval = *where; } while (compare_exchange(where, &oldval, oldval - 1) != FAILURE); return (oldval); /* * Five instructions in-line on i486. * 1: movl (%ebx), %eax * movl %eax, %edx * subl $1, %edx * cmpxchg (%ebx), %eax, %edx ; IIRC -- might be backwards * jc 1 */ } ...except that on some architectures, the right way to write it would be: long atomic_decrement_long(long *where) { long oldval; do { oldval = load_linked_long(where); } while (store_conditional(where, oldval - 1) != FAILURE); return (oldval); /* * Compiles to four or five instructions on an Alpha. */ } In this particular instance, you know that you just deleted the last reference if atomic_decrement_long returns an `old value' of > But that's just gross, expensive and shouldn't be needed. Nothing gross about it -- just ask any parallel algorithms geek. (Of which I am emphatically not one, I should point out.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 19:44:41 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 19:44:38 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id A278F37B400; Tue, 12 Dec 2000 19:44:38 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBD3iaF04877; Tue, 12 Dec 2000 19:44:36 -0800 (PST) Date: Tue, 12 Dec 2000 19:44:36 -0800 From: Alfred Perlstein To: Jason Evans Cc: Bosko Milekic , net@FreeBSD.ORG, jhb@FreeBSD.ORG Subject: Re: MEXT_IS_REF broken. Message-ID: <20001212194436.R16205@fw.wintelcom.net> References: <20001211014837.W16205@fw.wintelcom.net> <20001212014429.Y16205@fw.wintelcom.net> <20001212015059.Z16205@fw.wintelcom.net> <20001212143214.H2312@canonware.com> <20001212175937.M16205@fw.wintelcom.net> <20001212183930.L2312@canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001212183930.L2312@canonware.com>; from jasone@canonware.com on Tue, Dec 12, 2000 at 06:39:30PM -0800 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Jason Evans [001212 18:39] wrote: > On Tue, Dec 12, 2000 at 05:59:37PM -0800, Alfred Perlstein wrote: > > * Jason Evans [001212 14:32] wrote: > > > A safe version: > > > --------------------------------------------------------------------------- > > > #define MEXTFREE(m) do { \ > > > struct mbuf *_mmm = (m); \ > > > \ > > > MEXT_REM_REF(_mmm); \ > > > if (!atomic_cmpset_long(&_mmm->m_ext.ref_cnt->refcnt, 0, 1)) { \ > > > /* \ > > > * Do not free; there are still references, or another \ > > > * thread is freeing. \ > > > */ \ > > > } else if (_mmm->m_ext.ext_type != EXT_CLUSTER) { \ > > > (*(_mmm->m_ext.ext_free))(_mmm->m_ext.ext_buf, \ > > > _mmm->m_ext.ext_args); \ > > > _MEXT_DEALLOC_CNT(_mmm->m_ext.ref_cnt); \ > > > } else { \ > > > _MCLFREE(_mmm->m_ext.ext_buf); \ > > > _MEXT_DEALLOC_CNT(_mmm->m_ext.ref_cnt); \ > > > } \ > > > _mmm->m_flags &= ~M_EXT; \ > > > } while (0) > > > --------------------------------------------------------------------------- > > > > > > What this does is have all threads unconditionally atomically decrement. > > > Then, in order to determine whether to clean up, the threads to an atomic > > > compare and set on the refcount, so that if it is 0, only one thread > > > manages to modify the refcount, which then signifies that it will do the > > > cleanup. > > > > You've just proved why we need atomic ops that aren't so clumsy. > > > > Your solution doesn't work, the code is broken. > > > > You can't use atomic_cmpset_long to do a counter like that, it's > > the same race, you're just seeing if it goes to zero, now if it > > doesn't how do you decrement it? Use atomic_subtract_long? no, > > same race as the old code. > > Please read my code and explanation again. You seem to have missed the > order of arguments to atomic_cmpset_long(). The cmpset call detects > whether the refcount is already 0, and only allows one thread to increment > it; that thread then does the cleanup. Ok, can you please commit the fix then? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 19:47:33 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 19:47:30 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 6BBAA37B400 for ; Tue, 12 Dec 2000 19:47:30 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBD3lTG05005; Tue, 12 Dec 2000 19:47:29 -0800 (PST) Date: Tue, 12 Dec 2000 19:47:29 -0800 From: Alfred Perlstein To: Garrett Wollman Cc: net@FreeBSD.ORG Subject: Re: MEXT_IS_REF broken. Message-ID: <20001212194728.S16205@fw.wintelcom.net> References: <20001211014837.W16205@fw.wintelcom.net> <20001212014429.Y16205@fw.wintelcom.net> <20001212015059.Z16205@fw.wintelcom.net> <20001212143214.H2312@canonware.com> <20001212175937.M16205@fw.wintelcom.net> <200012130250.VAA55319@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200012130250.VAA55319@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Tue, Dec 12, 2000 at 09:50:19PM -0500 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Garrett Wollman [001212 18:50] wrote: > < said: > > > Actually, in truth I think you can get the code right like so: > > > long x = _mmm->m_ext.ref_cnt->refcnt; > > while (!atomic_cmpset_long(&_mmm->m_ext.ref_cnt->refcnt, x - 1, x)) > > ; > > Cool! You've just (almost) reinvented non-blocking parallel > reference-counts. Of course, what you really need is: > > long > atomic_decrement_long(long *where) > { > long oldval; > > do { > oldval = *where; > } while (compare_exchange(where, &oldval, oldval - 1) != FAILURE); > > return (oldval); > /* > * Five instructions in-line on i486. > * 1: movl (%ebx), %eax > * movl %eax, %edx > * subl $1, %edx > * cmpxchg (%ebx), %eax, %edx ; IIRC -- might be backwards > * jc 1 > */ > } Yeah, oops. :) It just goes to show how HAVING A CLEAR API for doing this might actually help us AVOID RACE CONDITIONS. *cough* > > ...except that on some architectures, the right way to write it would > be: > > long > atomic_decrement_long(long *where) > { > long oldval; > > do { > oldval = load_linked_long(where); > } while (store_conditional(where, oldval - 1) != FAILURE); > > return (oldval); > /* > * Compiles to four or five instructions on an Alpha. > */ > } > > In this particular instance, you know that you just deleted the last > reference if atomic_decrement_long returns an `old value' of > > > But that's just gross, expensive and shouldn't be needed. > > Nothing gross about it -- just ask any parallel algorithms geek. (Of > which I am emphatically not one, I should point out.) What Jason seems to be implying is that I must inline these functions by hand each time I want to do this instead of having an API for it. That's gross. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 19:47:50 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 19:47:48 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id A644837B400 for ; Tue, 12 Dec 2000 19:47:47 -0800 (PST) Received: (qmail 40015 invoked by uid 1142); 13 Dec 2000 03:47:46 -0000 Date: 12 Dec 2000 19:47:46 -0800 Date: Tue, 12 Dec 2000 19:46:59 -0800 From: Jason Evans To: Alfred Perlstein Cc: Bosko Milekic , net@FreeBSD.ORG Subject: Re: MEXT_IS_REF broken. Message-ID: <20001212194659.O2312@canonware.com> References: <20001211014837.W16205@fw.wintelcom.net> <20001212014429.Y16205@fw.wintelcom.net> <20001212015059.Z16205@fw.wintelcom.net> <20001212143214.H2312@canonware.com> <20001212175937.M16205@fw.wintelcom.net> <20001212183930.L2312@canonware.com> <20001212194436.R16205@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001212194436.R16205@fw.wintelcom.net>; from bright@wintelcom.net on Tue, Dec 12, 2000 at 07:44:36PM -0800 Sender: jasone@magnesium.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Dec 12, 2000 at 07:44:36PM -0800, Alfred Perlstein wrote: > Ok, can you please commit the fix then? Bosko is currently working up a patch that should be committed tonight sometime. By the way, thanks for the bug report. =) Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 20: 5: 3 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 20:05:01 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 8856E37B400 for ; Tue, 12 Dec 2000 20:05:00 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id eBD41gc95284; Tue, 12 Dec 2000 22:01:42 -0600 (CST) (envelope-from jlemon) Date: Tue, 12 Dec 2000 22:01:42 -0600 (CST) From: Jonathan Lemon Message-Id: <200012130401.eBD41gc95284@prism.flugsvamp.com> To: wollman@khavrinen.lcs.mit.edu, net@freebsd.org Subject: Re: MEXT_IS_REF broken. X-Newsgroups: local.mail.freebsd-net In-Reply-To: References: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you write: >< said: > >> Actually, in truth I think you can get the code right like so: > >> long x = _mmm->m_ext.ref_cnt->refcnt; >> while (!atomic_cmpset_long(&_mmm->m_ext.ref_cnt->refcnt, x - 1, x)) >> ; > >Cool! You've just (almost) reinvented non-blocking parallel >reference-counts. Of course, what you really need is: > >long >atomic_decrement_long(long *where) >{ > long oldval; > > do { > oldval = *where; > } while (compare_exchange(where, &oldval, oldval - 1) != FAILURE); Gee, this looks suspiciously like jhb's refcount patch: +static __inline int +refcount_release(refcount_t *count) +{ + int value; + + do { + value = *count - 1; + } while (!atomic_cmpset_rel_int(count, value + 1, value)); + return (value == 0); +} Sure you haven't been peeking at it? :-) :-) :-) -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 20:15:18 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 20:15:16 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id DCFF037B400 for ; Tue, 12 Dec 2000 20:15:15 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G5H001JDNTE56@field.videotron.net> for net@freebsd.org; Tue, 12 Dec 2000 23:15:14 -0500 (EST) Date: Tue, 12 Dec 2000 23:16:24 -0500 (EST) From: Bosko Milekic Subject: Re: need mbuf generic free() hook In-reply-to: <20001212042447.E16205@fw.wintelcom.net> To: Alfred Perlstein Cc: net@freebsd.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alfred, You've brought this up before. This looks familiar to your earlier post(s) regarding how to "abuse m_ext." Mind you, I may be mistaken, but that would be because this isn't being made awfully clear. Earlier you talked about forcing a custom free routine to be called even in the case of mbuf clusters, and we devised a way. Are you suggesting now to have a custom free routine called when your mbuf is freed (i.e. even when it is a non-M_EXT mbuf?) If that's so, I would urge you to re-examine the code because doing something like that would be generally wrong. I say "generally" because I'm always open to exceptions, as you know. So please clarify. On Tue, 12 Dec 2000, Alfred Perlstein wrote: > Ok, so I'm trying to rid FreeBSD of the unp_gc() junk in uipc_usrreq.c > I just realized why I'm leaking file descriptors: > > Only mbufs with external storage can have a 'free' function, the > problem is that for the most part when passing a single fd I'm only > using a single mbuf to pass my data around, my ext_free routine is > probably never called, and on top of that I'm probably corrupting > my mbuf by using it when I shouldn't be. > > This is terrible, what should be a simple free() hook is now my > worst nightmare. A couple of options come to mind: > > a) always have a free hook, the extra if (m->m_freehook != NULL) > check can't be that expensive. > b) a macro to make an mbuf into an mbuf cluster that points to itself, > it should check to see if it has enough room to shuffle the data > and return an error if it can't accomidate both the data and the > expanded mbug header. > > I like 'a' but would be willing to deal with 'b' as we've never > had a need for this, although that would mean copying about the > size of an mbuf in the worst case when a subsystem needs this > facility. > > Suggestions? Comments? > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." > > Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 20:26:39 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 20:26:37 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 37AB937B400 for ; Tue, 12 Dec 2000 20:26:33 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBD4QR906156; Tue, 12 Dec 2000 20:26:27 -0800 (PST) Date: Tue, 12 Dec 2000 20:26:27 -0800 From: Alfred Perlstein To: Bosko Milekic Cc: net@freebsd.org Subject: Re: need mbuf generic free() hook Message-ID: <20001212202626.U16205@fw.wintelcom.net> References: <20001212042447.E16205@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bmilekic@technokratis.com on Tue, Dec 12, 2000 at 11:16:24PM -0500 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Bosko Milekic [001212 20:15] wrote: > > Alfred, > > You've brought this up before. This looks familiar to your earlier > post(s) regarding how to "abuse m_ext." Mind you, I may be mistaken, but > that would be because this isn't being made awfully clear. > Earlier you talked about forcing a custom free routine to be called > even in the case of mbuf clusters, and we devised a way. > Are you suggesting now to have a custom free routine called when your > mbuf is freed (i.e. even when it is a non-M_EXT mbuf?) > If that's so, I would urge you to re-examine the code because doing > something like that would be generally wrong. I say "generally" because > I'm always open to exceptions, as you know. So please clarify. Look at "option b" I think that's a good way to go with this, basically being able to turn an mbuf into a mbuf that has its cluster pointer pointed at itself. > > On Tue, 12 Dec 2000, Alfred Perlstein wrote: > > > Ok, so I'm trying to rid FreeBSD of the unp_gc() junk in uipc_usrreq.c > > I just realized why I'm leaking file descriptors: > > > > Only mbufs with external storage can have a 'free' function, the > > problem is that for the most part when passing a single fd I'm only > > using a single mbuf to pass my data around, my ext_free routine is > > probably never called, and on top of that I'm probably corrupting > > my mbuf by using it when I shouldn't be. > > > > This is terrible, what should be a simple free() hook is now my > > worst nightmare. A couple of options come to mind: > > > > a) always have a free hook, the extra if (m->m_freehook != NULL) > > check can't be that expensive. > > b) a macro to make an mbuf into an mbuf cluster that points to itself, > > it should check to see if it has enough room to shuffle the data > > and return an error if it can't accomidate both the data and the > > expanded mbug header. > > > > I like 'a' but would be willing to deal with 'b' as we've never > > had a need for this, although that would mean copying about the > > size of an mbuf in the worst case when a subsystem needs this > > facility. > > > > Suggestions? Comments? > > > > -- > > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > > "I have the heart of a child; I keep it in a jar on my desk." > > > > > > > Bosko Milekic > bmilekic@technokratis.com > -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 12 21:59:22 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 21:59:20 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 628E637B400 for ; Tue, 12 Dec 2000 21:59:20 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA13458; Tue, 12 Dec 2000 21:59:20 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.11.0/8.11.0) id eBD5xJI43599; Tue, 12 Dec 2000 21:59:19 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200012130559.eBD5xJI43599@curve.dellroad.org> Subject: Re: Confusing netgraph error In-Reply-To: "from Mark Wright at Dec 11, 2000 04:19:09 pm" To: Mark Wright Date: Tue, 12 Dec 2000 21:59:19 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mark Wright writes: > sj# ngctl mkpeer lmc0: frame_relay rawdata downstream > sj# ngctl mkpeer lmc0:rawdata lmi dlci0 auto0 > sj# ngctl mkpeer lmc0:rawdata rfc1490 dlci15 downstream > ngctl: send msg: No such file or directory > > What does that mean? Should I be concerned that ifconfig -a doesn't reveal > the lmc0? Or does it show up only after I do a 'ngctl interface'? It shows > up in dmesg: > > lmc0: port 0xf880-0xf8ff mem 0xffbefc00-0xffbefc7f > irq 11 at device 16.0 on pci0 > lmc0: pass 2.2, serial 00:60:99:00:23:6d > lmc0: driver is using old-style compatability shims > > I'm using the 20001210 snapshot, and the following changes were made to my > kernel config: > > options NETGRAPH #enable netgraph networking > options NETGRAPH_SOCKET #enable netgraph networking > options NETGRAPH_FRAME_RELAY #enable frame relay > options NETGRAPH_LMI #enable link management > ... > device lmc # LanMedia card How about NETGRAPH_RFC1490? Use "kldstat -v | grep ng_" to see if you have all the necessary netgraph types (though it should load them automatically.. but then maybe the KLD file can't be found). -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 2:26:44 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 02:26:38 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 55E3B37B402; Wed, 13 Dec 2000 02:26:38 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBDAQcl15622; Wed, 13 Dec 2000 02:26:38 -0800 (PST) Date: Wed, 13 Dec 2000 02:26:38 -0800 From: Alfred Perlstein To: arch@freebsd.org Cc: net@freebsd.org Subject: patch to cleanup inflight desciptor handling. Message-ID: <20001213022637.A16205@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: bright@fw.wintelcom.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Not a lot of people are familiar with fd passing so I'll give a short description: By using AF_UNIX sockets between processes, a process can use sendmsg() to send a filedescriptor through the socket where the other process will do a recvmsg() to pickup the descriptor. The "problem" is that if a descriptor is in transit/inflight and the sending process closes the file, it still needs to remain open for the recipient. What can happen is: process A: sendmsg(descriptor) process A: exit process B: exit without the garbage collection we'd have leaked a file descriptor inside the kernel. There's a pretty complex loop in sys/kern/uipc_usrreq.c that deals with garbage collecting these inflight descriptors. The problem with the garbage collection routine is that: 1) it's expensive as it walks all the open files in the system at least twice. 2) it's ugly/hackish 3) it will need to aquire global locks on kernel structure lists for signifigant amounts of time. 4) complicates the code because certain things need to be done out of order, ie sorflush before sofree (which does the sorflush anyway). The solution is actually taken from Linux, in Linux all network buffers have the ability to have a free routine callback done on them when a network buffer is deallocated. FreeBSD only has a free routine available for M_EXT buffers (buffers with external storage), the routine is called when (m_flags & M_EXT) != 0 && m_type != EXT_CLUSTER To achieve my goal I made it so that all fd passing requires an mbuf cluster and took responsibility for freeing the mbuf cluster in my callback. I set m_type == EXT_CMSG_DATA and provide my own free routine until the descriptors are read by the recieving process, if the descriptors are read then i restore it back to a "normal" mbuf with an attached cluster to be free()'d. Good things about this patch: 1) simplifies a) locking b) descriptor management c) the code in general 2) less latency, the gc routine can be expensive 3) some comments are added describing some other stuff that needs fixing. (problems with rfork threads) 4) shrink struct file by one int Problems with this patch: 1) most fd passing probably only sends one descriptor at time, by allocating clusters I'm wasting a lot more space, and taking more time to do the allocation. 2) the mbuf subsystem should provide macros to do what I'm doing (hijacking the free routine on a mbuf+cluster) 3) the mbuf subsystem should provide a way to get a callback on a single mbuf without a cluster attached. http://people.FreeBSD.org/~alfred/inflight.diff thanks, -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 8: 5:26 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 08:05:24 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 19B7437B400 for ; Wed, 13 Dec 2000 08:05:23 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id LAA61096; Wed, 13 Dec 2000 11:04:55 -0500 (EST) (envelope-from wollman) Date: Wed, 13 Dec 2000 11:04:55 -0500 (EST) From: Garrett Wollman Message-Id: <200012131604.LAA61096@khavrinen.lcs.mit.edu> To: Jonathan Lemon Cc: net@FreeBSD.ORG Subject: Re: MEXT_IS_REF broken. In-Reply-To: <200012130401.eBD41gc95284@prism.flugsvamp.com> References: <200012130401.eBD41gc95284@prism.flugsvamp.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Gee, this looks suspiciously like jhb's refcount patch: ...Except that I made provision for architectures which have LL/SC rather than CAS, which saves a few instructions. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 8:20:55 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 08:20:52 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 3073737B402 for ; Wed, 13 Dec 2000 08:20:52 -0800 (PST) Received: from victoria-093.budapest.interware.hu ([195.70.63.93] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 146EeA-00044w-00; Wed, 13 Dec 2000 17:20:50 +0100 Sender: julian@FreeBSD.ORG Message-ID: <3A37A13B.E903D658@elischer.org> Date: Wed, 13 Dec 2000 08:18:03 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Mark Wright Cc: freebsd-net@freebsd.org Subject: Re: Confusing netgraph error References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mark Wright wrote: > > I'm trying to get frame relay working with a lmc1200 card, and I'm getting > the following error: > > sj# ngctl mkpeer lmc0: frame_relay rawdata downstream > sj# ngctl mkpeer lmc0:rawdata lmi dlci0 auto0 > sj# ngctl mkpeer lmc0:rawdata rfc1490 dlci15 downstream > ngctl: send msg: No such file or directory > > What does that mean? Should I be concerned that ifconfig -a doesn't reveal > the lmc0? Or does it show up only after I do a 'ngctl interface'? It shows > up in dmesg: > > lmc0: port 0xf880-0xf8ff mem 0xffbefc00-0xffbefc7f > irq 11 at device 16.0 on pci0 > lmc0: pass 2.2, serial 00:60:99:00:23:6d > lmc0: driver is using old-style compatability shims > > I'm using the 20001210 snapshot, and the following changes were made to my > kernel config: > > options NETGRAPH #enable netgraph networking > options NETGRAPH_SOCKET #enable netgraph networking > options NETGRAPH_FRAME_RELAY #enable frame relay > options NETGRAPH_LMI #enable link management > ... > device lmc # LanMedia card duh, I didn't notice but archie caught it.. you apparently haven;t compiled in the rfc1490 node.. no probelm, it's a module so just type: kldload ng_rfc1490 and try again. > > Mark > > markscottwright@hotmail.com > > _____________________________________________________________________________________ > Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 10:51:33 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 10:51:31 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id 55FA437B400; Wed, 13 Dec 2000 10:51:31 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G5I00935SDDN1@field.videotron.net>; Wed, 13 Dec 2000 13:51:13 -0500 (EST) Date: Wed, 13 Dec 2000 13:52:25 -0500 (EST) From: Bosko Milekic Subject: Ratelimint Enhancement patch (Please Review One Last Time!) To: freebsd-net@freebsd.org Cc: green@freebsd.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, A while ago (it's been at least two weeks now), Mike Silbersack requested a review for: http://www.silby.com/patches/ratelimit-enhancement-2.patch To quote the description on his web page, this diff will: * ICMP ECHO and TSTAMP replies are now rate-limited. * RSTs generated due to packets sent to open and unopen ports are now seperated into separate queues. * Each rate limiting queue now has its own description, as follows: Suppressing udp flood/scan: 212/200 pps Suppressing outgoing RST due to port scan: 202/200 pps Suppressing outgoing RST due to ACK flood: 19725/200 pps Suppressing ping flood: 230/200 pps Suppressing icmp tstamp flood: 210/200 pps While the descriptions for the two RST cases can be accused of oversimplification, they should cut down on questions by users confused with the current terminology. Experienced users can always run a packet sniffer if they need more exact knowledge of what's occuring. The diff was initially reviewed by me and green, and the recommended changes were mainly stylistic. I want to commit this code, but I'm posting it up here in case someone has any final objections or review. Thanks, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 10:52:53 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 10:52:51 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id D1C2A37B400; Wed, 13 Dec 2000 10:52:50 -0800 (PST) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.9.3/8.9.3) with ESMTP id KAA17423; Wed, 13 Dec 2000 10:52:49 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200012131852.KAA17423@beastie.mckusick.com> To: Alfred Perlstein Subject: Re: patch to cleanup inflight desciptor handling. Cc: arch@freebsd.org, net@freebsd.org In-Reply-To: Your message of "Wed, 13 Dec 2000 02:26:38 PST." <20001213022637.A16205@fw.wintelcom.net> Date: Wed, 13 Dec 2000 10:52:49 -0800 From: Kirk McKusick Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I believe that your changes have been sorely needed for many years. While I would like to see regular mbufs given a callback mechanism, your present approach of using an mbuf cluster solves 90% of the problem. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 11:17:20 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 11:17:15 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [207.91.110.247]) by hub.freebsd.org (Postfix) with ESMTP id 755EB37B400; Wed, 13 Dec 2000 11:17:15 -0800 (PST) Received: by overlord.e-gerbil.net (Postfix, from userid 1001) id 0E886E4F4D; Wed, 13 Dec 2000 14:16:53 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by overlord.e-gerbil.net (Postfix) with ESMTP id E3B25E4F4C; Wed, 13 Dec 2000 14:16:53 -0500 (EST) Date: Wed, 13 Dec 2000 14:16:53 -0500 (EST) From: "Richard A. Steenbergen" To: Bosko Milekic Cc: freebsd-net@freebsd.org, green@freebsd.org Subject: Re: Ratelimint Enhancement patch (Please Review One Last Time!) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 13 Dec 2000, Bosko Milekic wrote: > Suppressing udp flood/scan: 212/200 pps > Suppressing outgoing RST due to port scan: 202/200 pps > Suppressing outgoing RST due to ACK flood: 19725/200 pps > Suppressing ping flood: 230/200 pps > Suppressing icmp tstamp flood: 210/200 pps > > While the descriptions for the two RST cases can be accused > of oversimplification, they should cut down on questions by > users confused with the current terminology. Experienced > users can always run a packet sniffer if they need more > exact knowledge of what's occuring. I would be extremely careful with those descriptions... When you tell people directly that something is an attack, even if its not, there are enough who will jump to immediate conclusions and begin making false accusations. While it may be highly likely that the reasons for those rate limits is some kind of attack, it is not guaranteed, and I would be very reluctant to so blatantly tell people that it is... Personally I'd recommend straight forward descriptions like "RST due to no listening socket". I also see no compelling reason to put ICMP Timestamp in a seperate queue, but what I would recommend is seperate queues for ICMP messages which would be defined as "query/response" and those which would be called "error" messages. If someone needs more specific protection they can use dummynet. Just a thought... -- Richard A Steenbergen http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 11:29:51 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 11:29:49 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 9B09C37B400; Wed, 13 Dec 2000 11:29:49 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBDJTZA29071; Wed, 13 Dec 2000 11:29:35 -0800 (PST) Date: Wed, 13 Dec 2000 11:29:35 -0800 From: Alfred Perlstein To: "Richard A. Steenbergen" Cc: Bosko Milekic , freebsd-net@FreeBSD.ORG, green@FreeBSD.ORG Subject: Re: Ratelimint Enhancement patch (Please Review One Last Time!) Message-ID: <20001213112935.K16205@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ras@e-gerbil.net on Wed, Dec 13, 2000 at 02:16:53PM -0500 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Richard A. Steenbergen [001213 11:17] wrote: > On Wed, 13 Dec 2000, Bosko Milekic wrote: > > > Suppressing udp flood/scan: 212/200 pps > > Suppressing outgoing RST due to port scan: 202/200 pps > > Suppressing outgoing RST due to ACK flood: 19725/200 pps > > Suppressing ping flood: 230/200 pps > > Suppressing icmp tstamp flood: 210/200 pps > > > > While the descriptions for the two RST cases can be accused > > of oversimplification, they should cut down on questions by > > users confused with the current terminology. Experienced > > users can always run a packet sniffer if they need more > > exact knowledge of what's occuring. > > I would be extremely careful with those descriptions... When you tell > people directly that something is an attack, even if its not, there are > enough who will jump to immediate conclusions and begin making false > accusations. While it may be highly likely that the reasons for those rate > limits is some kind of attack, it is not guaranteed, and I would be very > reluctant to so blatantly tell people that it is... > > Personally I'd recommend straight forward descriptions like "RST due to no > listening socket". I also see no compelling reason to put ICMP Timestamp > in a seperate queue, but what I would recommend is seperate queues for > ICMP messages which would be defined as "query/response" and those which > would be called "error" messages. If someone needs more specific > protection they can use dummynet. > > Just a thought... I think the word "possible" should be prepended to all of these messages. Now I have a weird question, I've seen the ICMP responce limit when getting pegged by a couple hundred hits per second on a port that isn't open by legimitimate connections. This would probably fall under: > > Suppressing outgoing RST due to port scan: 202/200 pps Which is untrue, it should read something like: Suppressing outgoing RST due to high rate of connections on an unopen port (possible portscan): 202/200 pps -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 11:36: 6 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 11:36:04 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-c.mdsn1.wi.home.com [24.183.3.139]) by hub.freebsd.org (Postfix) with ESMTP id 05C9437B402 for ; Wed, 13 Dec 2000 11:36:04 -0800 (PST) Received: (qmail 13669 invoked by uid 1000); 13 Dec 2000 19:36:02 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 13 Dec 2000 19:36:02 -0000 Date: Wed, 13 Dec 2000 13:36:02 -0600 (CST) From: Mike Silbersack To: "Richard A. Steenbergen" Cc: Bosko Milekic , freebsd-net@freebsd.org, green@freebsd.org Subject: Re: Ratelimint Enhancement patch (Please Review One Last Time!) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 13 Dec 2000, Richard A. Steenbergen wrote: > I would be extremely careful with those descriptions... When you tell > people directly that something is an attack, even if its not, there are > enough who will jump to immediate conclusions and begin making false > accusations. While it may be highly likely that the reasons for those rate > limits is some kind of attack, it is not guaranteed, and I would be very > reluctant to so blatantly tell people that it is... > > Personally I'd recommend straight forward descriptions like "RST due to no > listening socket". Well, as no IPs are listed, I'm not too concerned about libelous attack accusations resulting from the messages. However, I'm not opposed to changing the messages, as long as the distinction between the cases is clear. Do you have exact replacements for each case along the line of what you're thinking of? (Making it fit into 80 characters is the tough part.) > I also see no compelling reason to put ICMP Timestamp > in a seperate queue, but what I would recommend is seperate queues for > ICMP messages which would be defined as "query/response" and those which > would be called "error" messages. If someone needs more specific > protection they can use dummynet. Well, I should make a clarification here. My use of the word queue is wrong. All the rate limiting does is count packets per second and drop those above the allowed amount. Hence, there's no significant overhead to having counters for each seperate type. The main reason tstamp is distinct from echo is so that they can be reported correctly. Given that they are distinctly different packets, I think this makes sense. (And has less overhead than dummynet would.) Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 11:43:21 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 11:43:19 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [207.91.110.247]) by hub.freebsd.org (Postfix) with ESMTP id DB56937B400; Wed, 13 Dec 2000 11:43:18 -0800 (PST) Received: by overlord.e-gerbil.net (Postfix, from userid 1001) id F04C7E4F4D; Wed, 13 Dec 2000 14:42:53 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by overlord.e-gerbil.net (Postfix) with ESMTP id C0B54E4F4C; Wed, 13 Dec 2000 14:42:53 -0500 (EST) Date: Wed, 13 Dec 2000 14:42:53 -0500 (EST) From: "Richard A. Steenbergen" To: Alfred Perlstein Cc: Bosko Milekic , freebsd-net@FreeBSD.ORG, green@FreeBSD.ORG Subject: Re: Ratelimint Enhancement patch (Please Review One Last Time!) In-Reply-To: <20001213112935.K16205@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 13 Dec 2000, Alfred Perlstein wrote: > I think the word "possible" should be prepended to all of these messages. > > Now I have a weird question, I've seen the ICMP responce limit when > getting pegged by a couple hundred hits per second on a port that isn't > open by legimitimate connections. > > This would probably fall under: > > > Suppressing outgoing RST due to port scan: 202/200 pps > > Which is untrue, it should read something like: > Suppressing outgoing RST due to high rate of connections on an unopen > port (possible portscan): 202/200 pps It could just as easily be a SYN flood against a single port... or a large number of clients trying to connected to your crashed web server... :P Or it could just as easily be an ack flood against a port without a listener and be showing up in the "not the ack flood" counter. Attaching motives and trying to play intrusion detection pattern analysis games without complete information is dangerous, and none of these routines qualify as advanced enough to make any such determination. IMHO break it down by "RST from ports with or without a listener" (or open port, whatever floats the boat) and be done with it. The major goal of this code would seem to be to provide simple but fairly useful protection against common attacks out of the box, not to provide analysis of the attacks (since no useful analysis can be performed without looking further anyways). -- Richard A Steenbergen http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 11:54:52 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 11:54:50 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [207.91.110.247]) by hub.freebsd.org (Postfix) with ESMTP id 19CEE37B400; Wed, 13 Dec 2000 11:54:46 -0800 (PST) Received: by overlord.e-gerbil.net (Postfix, from userid 1001) id B35D3E4F4D; Wed, 13 Dec 2000 14:54:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by overlord.e-gerbil.net (Postfix) with ESMTP id 93879E4F4C; Wed, 13 Dec 2000 14:54:30 -0500 (EST) Date: Wed, 13 Dec 2000 14:54:30 -0500 (EST) From: "Richard A. Steenbergen" To: Mike Silbersack Cc: Bosko Milekic , freebsd-net@freebsd.org, green@freebsd.org Subject: Re: Ratelimint Enhancement patch (Please Review One Last Time!) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 13 Dec 2000, Mike Silbersack wrote: > > I also see no compelling reason to put ICMP Timestamp > > in a seperate queue, but what I would recommend is seperate queues for > > ICMP messages which would be defined as "query/response" and those which > > would be called "error" messages. If someone needs more specific > > protection they can use dummynet. > > Well, I should make a clarification here. My use of the word queue is > wrong. All the rate limiting does is count packets per second and drop > those above the allowed amount. Hence, there's no significant overhead > to having counters for each seperate type. > > The main reason tstamp is distinct from echo is so that they can be > reported correctly. Given that they are distinctly different packets, I > think this makes sense. (And has less overhead than dummynet would.) Is there some specific reason you need timestamp seperate? If you're really up for that, why not just limit each ICMP type seperately? As for performance, this limiting occurs deeper in the stack then ipfw, and w/dummynet you have the flexability to mask the ips so that each interface or aliased ip could have a seperate rate limit as well. My thinking on the matter is that these limits should provide basic protection out of the box, and site specific limits should be done with dummynet. I personally agree with this patch because I think there should be seperate limits at some fundimental level, such as tcp-closed tcp-open udp(closed) icmp-response and icmp-error. How much further you want to push it is debatable mainly just because of the hastle of too many unnecessary tunables, not for any real performance or memory reasons. -- Richard A Steenbergen http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 12: 9:48 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 12:09:47 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-c.mdsn1.wi.home.com [24.183.3.139]) by hub.freebsd.org (Postfix) with ESMTP id E2A3E37B402 for ; Wed, 13 Dec 2000 12:09:46 -0800 (PST) Received: (qmail 13717 invoked by uid 1000); 13 Dec 2000 20:09:46 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 13 Dec 2000 20:09:46 -0000 Date: Wed, 13 Dec 2000 14:09:46 -0600 (CST) From: Mike Silbersack To: "Richard A. Steenbergen" Cc: Bosko Milekic , freebsd-net@freebsd.org, green@freebsd.org Subject: Re: Ratelimint Enhancement patch (Please Review One Last Time!) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 13 Dec 2000, Richard A. Steenbergen wrote: > Is there some specific reason you need timestamp seperate? If you're > really up for that, why not just limit each ICMP type seperately? There's no real need for it to be separate, it just feels cleaner. I prefer seeing the two cases have separately reported values. (Have I missed any icmp types that a host could respond with? If so, please tell me so that I can add them.) > As for performance, this limiting occurs deeper in the stack then ipfw, > and w/dummynet you have the flexability to mask the ips so that each > interface or aliased ip could have a seperate rate limit as well. Hm, true. I was thinking of limiting the outgoing side, which would mean ipfw comes later in the string, but I suppose that if you limit on the incoming ipfw's sooner. > My thinking on the matter is that these limits should provide basic > protection out of the box, and site specific limits should be done with > dummynet. I personally agree with this patch because I think there should > be seperate limits at some fundimental level, such as tcp-closed tcp-open > udp(closed) icmp-response and icmp-error. How much further you want to > push it is debatable mainly just because of the hastle of too many > unnecessary tunables, not for any real performance or memory reasons. I wasn't planning to subdivide the reporting any more in future patches, so you shouldn't see any new tunables popping up for that reason. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 12:26:13 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 12:26:11 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [207.91.110.247]) by hub.freebsd.org (Postfix) with ESMTP id A835437B402; Wed, 13 Dec 2000 12:26:09 -0800 (PST) Received: by overlord.e-gerbil.net (Postfix, from userid 1001) id A5416E4F4D; Wed, 13 Dec 2000 15:25:58 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by overlord.e-gerbil.net (Postfix) with ESMTP id 89E32E4F4C; Wed, 13 Dec 2000 15:25:58 -0500 (EST) Date: Wed, 13 Dec 2000 15:25:58 -0500 (EST) From: "Richard A. Steenbergen" To: Mike Silbersack Cc: Bosko Milekic , freebsd-net@freebsd.org, green@freebsd.org Subject: Re: Ratelimint Enhancement patch (Please Review One Last Time!) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 13 Dec 2000, Mike Silbersack wrote: > On Wed, 13 Dec 2000, Richard A. Steenbergen wrote: > > > Is there some specific reason you need timestamp seperate? If you're > > really up for that, why not just limit each ICMP type seperately? > > There's no real need for it to be separate, it just feels cleaner. I > prefer seeing the two cases have separately reported values. (Have I > missed any icmp types that a host could respond with? If so, please tell > me so that I can add them.) Assuming the box is not acting as a router in any fashion... It doesn't matter, it really doesn't, I'm just note sure timestamp is really worth the hastle instead of just calling it icmp request... The advantage of seperate limits is to keep one service working when another is being limited. Since its a dirt simple operation to pick which limit you're hitting, and there are no queues involved just counters, it might be just as easy to go into the rate limiting function as icmp limit, and have it maintain seperate limits for every type, if you really wanted... > > As for performance, this limiting occurs deeper in the stack then ipfw, > > and w/dummynet you have the flexability to mask the ips so that each > > interface or aliased ip could have a seperate rate limit as well. > > Hm, true. I was thinking of limiting the outgoing side, which would mean > ipfw comes later in the string, but I suppose that if you limit on the > incoming ipfw's sooner. Historically bandlim has been the process of stopping the processing at input of things which would result in output... Do you want to (or need to) extend this? > I wasn't planning to subdivide the reporting any more in future patches, > so you shouldn't see any new tunables popping up for that reason. Same question as above, is this to be built in Denail of Service prevention, or is this limiting of packets which could potentially generate excessive processing or replies? Might as well do it right instead of kludging this up any more... :P -- Richard A Steenbergen http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 12:40:56 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 12:40:55 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-c.mdsn1.wi.home.com [24.183.3.139]) by hub.freebsd.org (Postfix) with ESMTP id C1A2B37B400 for ; Wed, 13 Dec 2000 12:40:54 -0800 (PST) Received: (qmail 13776 invoked by uid 1000); 13 Dec 2000 20:40:54 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 13 Dec 2000 20:40:54 -0000 Date: Wed, 13 Dec 2000 14:40:54 -0600 (CST) From: Mike Silbersack To: "Richard A. Steenbergen" Cc: Bosko Milekic , freebsd-net@freebsd.org, green@freebsd.org Subject: Re: Ratelimint Enhancement patch (Please Review One Last Time!) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 13 Dec 2000, Richard A. Steenbergen wrote: > > Hm, true. I was thinking of limiting the outgoing side, which would mean > > ipfw comes later in the string, but I suppose that if you limit on the > > incoming ipfw's sooner. > > Historically bandlim has been the process of stopping the processing at > input of things which would result in output... Do you want to (or need > to) extend this? Since this code actually has to read the incoming packets before decidied to not send the outgoing reply, I consider it to be dropping the outgoing. However, since there's no useful info in a icmp request, reading isn't really anything... We appear to be caught in a semantical argument, I'm not proposing anything new. > Same question as above, is this to be built in Denail of Service > prevention, or is this limiting of packets which could potentially > generate excessive processing or replies? Might as well do it right > instead of kludging this up any more... :P It just limits the bandwidth of mostly useless packets. What constitutes a "DoS" is beyond the scope of this message, and we're starting to nitpick. I'll roll an updated patch with less casual messages so we can get it committed soon. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 13: 7: 3 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 13:06:59 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id ABD8A37B699; Wed, 13 Dec 2000 13:06:59 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eBDL6Sg86570; Wed, 13 Dec 2000 13:06:28 -0800 (PST) (envelope-from dillon) Date: Wed, 13 Dec 2000 13:06:28 -0800 (PST) From: Matt Dillon Message-Id: <200012132106.eBDL6Sg86570@earth.backplane.com> To: Kirk McKusick Cc: Alfred Perlstein , arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: patch to cleanup inflight desciptor handling. References: <200012131852.KAA17423@beastie.mckusick.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :I believe that your changes have been sorely needed for many :years. While I would like to see regular mbufs given a callback :mechanism, your present approach of using an mbuf cluster :solves 90% of the problem. : : Kirk McKusick ... Aflred, be careful that you don't break things we only just fixed last year. The descriptor passing code has been broken for many years. I think the reason we have to scan the descriptor list is related to locating isolated self-referential 'loops' with descriptor passing and unix domain sockets and closing them. e.g. when you pass a descriptor for a unix-domain socket through a unix-domain socket, it is possible for the socket descriptors to reference each other and thus never have their ref count drop to 0 even when all associated processes have close()'d. This happens all the time. Be sure you don't break the fix that solves that particular problem. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 13:10:26 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 13:10:23 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [207.91.110.247]) by hub.freebsd.org (Postfix) with ESMTP id 5EECF37B698; Wed, 13 Dec 2000 13:10:20 -0800 (PST) Received: by overlord.e-gerbil.net (Postfix, from userid 1001) id 11581E4F4D; Wed, 13 Dec 2000 16:09:50 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by overlord.e-gerbil.net (Postfix) with ESMTP id D1F24E4F4C; Wed, 13 Dec 2000 16:09:50 -0500 (EST) Date: Wed, 13 Dec 2000 16:09:50 -0500 (EST) From: "Richard A. Steenbergen" To: Mike Silbersack Cc: Bosko Milekic , freebsd-net@freebsd.org, green@freebsd.org Subject: Re: Ratelimint Enhancement patch (Please Review One Last Time!) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 13 Dec 2000, Mike Silbersack wrote: > On Wed, 13 Dec 2000, Richard A. Steenbergen wrote: > > > > Hm, true. I was thinking of limiting the outgoing side, which would mean > > > ipfw comes later in the string, but I suppose that if you limit on the > > > incoming ipfw's sooner. > > > > Historically bandlim has been the process of stopping the processing at > > input of things which would result in output... Do you want to (or need > > to) extend this? > > Since this code actually has to read the incoming packets before decidied > to not send the outgoing reply, I consider it to be dropping the > outgoing. However, since there's no useful info in a icmp request, > reading isn't really anything... We appear to be caught in a semantical > argument, I'm not proposing anything new. There is a difference though, if you're stopping excessive requests at input, or stopping the replies from hitting the network after bothing to process them, which is what I ment about using ipfw at input. Right now it has to be classified as dropping on incoming, with the qualifier that we're dropping at incoming things which would result in further processing and an outgoing reply. Entirely semantics but still. > > Same question as above, is this to be built in Denail of Service > > prevention, or is this limiting of packets which could potentially > > generate excessive processing or replies? Might as well do it right > > instead of kludging this up any more... :P > > It just limits the bandwidth of mostly useless packets. What constitutes > a "DoS" is beyond the scope of this message, and we're starting to > nitpick. I'll roll an updated patch with less casual messages so we can > get it committed soon. Well my point is, if you're compiling BANDLIM into your kernel and end up getting messages on possible port scans, this is backwards. If you really want to make a DoS analysis and prevention system, I think it should be seperate from this. -- Richard A Steenbergen http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 13:23: 2 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 13:22:55 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 9188037B402; Wed, 13 Dec 2000 13:22:53 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.1/8.11.1) with ESMTP id eBDLKcZ03838; Wed, 13 Dec 2000 21:20:39 GMT (envelope-from brian@lan.awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.1/8.11.1) with ESMTP id eBDLOBU68538; Wed, 13 Dec 2000 21:24:11 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200012132124.eBDLOBU68538@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Alfred Perlstein Cc: arch@FreeBSD.ORG, net@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: patch to cleanup inflight desciptor handling. In-Reply-To: Message from Alfred Perlstein of "Wed, 13 Dec 2000 02:26:38 PST." <20001213022637.A16205@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Dec 2000 21:24:11 +0000 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Not a lot of people are familiar with fd passing so I'll give > a short description: > > By using AF_UNIX sockets between processes, a process can use > sendmsg() to send a filedescriptor through the socket where the > other process will do a recvmsg() to pickup the descriptor. > > The "problem" is that if a descriptor is in transit/inflight > and the sending process closes the file, it still needs to > remain open for the recipient. > > What can happen is: > > process A: sendmsg(descriptor) > process A: exit > process B: exit > > without the garbage collection we'd have leaked a file descriptor > inside the kernel. [.....] Hmm, the last time i looked at this, I believe the whole thing was dealt with by not increasing the file descriptor reference count when it was put in the message header. If process A closed the descriptor before process B actually recvmsg()d it, it would be EBADF. The recvmsg() actually incremented the reference count. I always assumed that this was a result of not wanting to have any funny garbage collecting code ? Of course looking at the code now, it increases fp->f_count in unp_internalize(), so maybe I was on drugs then.... Assuming I wasn't on drugs (maybe the behaviour was changed - cvs annotate suggests some activity around March 9, but that was the file*/int alignment stuff), I think it would be valid to go back to the old behaviour (not increasing f_count and letting the original owner actually close the descriptor while f_msgcount != 0). Does any of this make sense ? Or am I just describing a different case (where process B doesn't exit) ? > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 14:19:25 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 14:19:19 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 9234437B698; Wed, 13 Dec 2000 14:19:19 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBDMJIx04918; Wed, 13 Dec 2000 14:19:18 -0800 (PST) Date: Wed, 13 Dec 2000 14:19:18 -0800 From: Alfred Perlstein To: Matt Dillon Cc: Kirk McKusick , arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: patch to cleanup inflight desciptor handling. Message-ID: <20001213141917.Q16205@fw.wintelcom.net> References: <200012131852.KAA17423@beastie.mckusick.com> <200012132106.eBDL6Sg86570@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200012132106.eBDL6Sg86570@earth.backplane.com>; from dillon@earth.backplane.com on Wed, Dec 13, 2000 at 01:06:28PM -0800 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Matt Dillon [001213 13:07] wrote: > :I believe that your changes have been sorely needed for many > :years. While I would like to see regular mbufs given a callback > :mechanism, your present approach of using an mbuf cluster > :solves 90% of the problem. > : > : Kirk McKusick > > ... Aflred, be careful that you don't break things we only just fixed > last year. The descriptor passing code has been broken for many years. > > I think the reason we have to scan the descriptor list is related to > locating isolated self-referential 'loops' with descriptor passing and > unix domain sockets and closing them. e.g. when you pass a descriptor > for a unix-domain socket through a unix-domain socket, it is possible > for the socket descriptors to reference each other and thus never have > their ref count drop to 0 even when all associated processes have > close()'d. This happens all the time. Be sure you don't break the > fix that solves that particular problem. Ok, I'll see if that can happen. Basically since the reference never goes to zero on the socket, the buffers are never forced to be flushed/cleared and the mbuf will then never be free'd resulting it it leaking itself. Basically a socket hanging there with an mbuf referencing itself. I wonder if Linux fixed/has this problem. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 14:53:50 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 14:53:44 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 65D9737B404; Wed, 13 Dec 2000 14:53:42 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBDMrff06270; Wed, 13 Dec 2000 14:53:41 -0800 (PST) Date: Wed, 13 Dec 2000 14:53:41 -0800 From: Alfred Perlstein To: Matt Dillon Cc: Kirk McKusick , arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: patch to cleanup inflight desciptor handling. Message-ID: <20001213145341.S16205@fw.wintelcom.net> References: <200012131852.KAA17423@beastie.mckusick.com> <200012132106.eBDL6Sg86570@earth.backplane.com> <20001213141917.Q16205@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001213141917.Q16205@fw.wintelcom.net>; from bright@wintelcom.net on Wed, Dec 13, 2000 at 02:19:18PM -0800 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Alfred Perlstein [001213 14:20] wrote: > * Matt Dillon [001213 13:07] wrote: > > :I believe that your changes have been sorely needed for many > > :years. While I would like to see regular mbufs given a callback > > :mechanism, your present approach of using an mbuf cluster > > :solves 90% of the problem. > > : > > : Kirk McKusick > > > > ... Aflred, be careful that you don't break things we only just fixed > > last year. The descriptor passing code has been broken for many years. > > > > I think the reason we have to scan the descriptor list is related to > > locating isolated self-referential 'loops' with descriptor passing and > > unix domain sockets and closing them. e.g. when you pass a descriptor > > for a unix-domain socket through a unix-domain socket, it is possible > > for the socket descriptors to reference each other and thus never have > > their ref count drop to 0 even when all associated processes have > > close()'d. This happens all the time. Be sure you don't break the > > fix that solves that particular problem. > > Ok, I'll see if that can happen. Basically since the reference > never goes to zero on the socket, the buffers are never forced to > be flushed/cleared and the mbuf will then never be free'd resulting > it it leaking itself. Basically a socket hanging there with an > mbuf referencing itself. > > I wonder if Linux fixed/has this problem. Ok, my patch has this problem: void parent(int con) { int fd; fd = open("/tmp/wank", O_RDONLY); send_fd_withdata(con, con, "wank", 4); sleep (5); exit(1); } void child(int con) { int fd, error; char buf[100]; sleep(5); get_fd_withdata(con, &fd, buf, sizeof(buf)); send_fd_withdata(con, fd, "foo", 3); exit(1); buf[4] = '\0'; printf("%s\n", buf); if ((error = read(fd, buf, sizeof(buf))) < 0) perror("read"); buf[sizeof(buf)-1] = '\0'; printf("%s\n", buf); } This causes a leak, I think the trick is to just always call sorflush() when the pcb is free'd. Looking at linux they still are using gc. I'll give this a lot more thought before resubmitting this idea. sorry, -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 14:58:29 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 14:58:26 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 7CFD637B402; Wed, 13 Dec 2000 14:58:22 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.15 #3) id 146KqP-00094D-00; Wed, 13 Dec 2000 22:57:53 +0000 Date: Wed, 13 Dec 2000 22:57:53 +0000 From: Tony Finch To: Brian Somers Cc: Alfred Perlstein , arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: patch to cleanup inflight desciptor handling. Message-ID: <20001213225753.B30050@hand.dotat.at> References: <200012132124.eBDLOBU68538@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200012132124.eBDLOBU68538@hak.lan.Awfulhak.org> Organization: Covalent Technologies, Inc Sender: fanf@dotat.at Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brian Somers wrote: > >Hmm, the last time i looked at this, I believe the whole thing was >dealt with by not increasing the file descriptor reference count >when it was put in the message header. If process A closed the >descriptor before process B actually recvmsg()d it, it would be >EBADF. The recvmsg() actually incremented the reference count. But it has always been documented behaviour that the receiving process gets a valid descriptor even if the sender closes it directly after sendmsging it. If this was not the case then descriptor handoff would require an "ok" reply from the receiving process before the sender could close it, which is a pain. Hmm, the only references for this I can think of are Stevens and the red & black daemon books, but I'm sure I've read a good discussion of it somewhere else. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at "And remember my friend, future events such as these will affect you in the future." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 15:36:55 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 15:36:51 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id CBF2B37B402; Wed, 13 Dec 2000 15:36:50 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBDNan707825; Wed, 13 Dec 2000 15:36:49 -0800 (PST) Date: Wed, 13 Dec 2000 15:36:49 -0800 From: Alfred Perlstein To: Matt Dillon Cc: Kirk McKusick , arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: patch to cleanup inflight desciptor handling. Message-ID: <20001213153649.T16205@fw.wintelcom.net> References: <200012131852.KAA17423@beastie.mckusick.com> <200012132106.eBDL6Sg86570@earth.backplane.com> <20001213141917.Q16205@fw.wintelcom.net> <20001213145341.S16205@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001213145341.S16205@fw.wintelcom.net>; from bright@wintelcom.net on Wed, Dec 13, 2000 at 02:53:41PM -0800 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > This causes a leak, I think the trick is to just always call sorflush() > when the pcb is free'd. Even this doesn't work. > > Looking at linux they still are using gc. I'll give this a lot > more thought before resubmitting this idea. Ok, the problem is you have 3 af_unix pairs all open between 2 processes process B sends 3 over 2 to A process B sends 2 over 3 to A process B send 2 and 3 over 1 to A process B closes 1 2 and 3 A then closes 3 2 and then 1 closing 3 and 2 doesn't cause the socketbuffer to be flushed because they are still self referencing. closing 1 causes the socketbuffer to be flushed, on flushing it comes across 2 and drops a reference but doesn't flush, it then hits 3 and drops a reference but doesn't flush. since 3 references 2 and 2 references 3 and nothing else references 2 or 3, we just leaked 2 and 3. I guess the gc has to stay. dammit. :) My apologies for wasting everyone's time here. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 15:48:12 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 15:48:08 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 2923737B404; Wed, 13 Dec 2000 15:48:08 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.15 #3) id 146Lcp-000Ale-00; Wed, 13 Dec 2000 23:47:55 +0000 Date: Wed, 13 Dec 2000 23:47:55 +0000 From: Tony Finch To: Alfred Perlstein Cc: Matt Dillon , Kirk McKusick , arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: patch to cleanup inflight desciptor handling. Message-ID: <20001213234755.U71002@hand.dotat.at> References: <200012131852.KAA17423@beastie.mckusick.com> <200012132106.eBDL6Sg86570@earth.backplane.com> <20001213141917.Q16205@fw.wintelcom.net> <20001213145341.S16205@fw.wintelcom.net> <20001213153649.T16205@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20001213153649.T16205@fw.wintelcom.net> Organization: Covalent Technologies, Inc Sender: fanf@dotat.at Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alfred Perlstein wrote: > >I guess the gc has to stay. > >dammit. :) > >My apologies for wasting everyone's time here. ``One day a student came to Moon and said: "I understand how to make a better garbage collector. We must keep a reference count of the pointers to each cons." ``Moon patiently told the student the following story: ``"One day a student came to Moon and said: `I understand how to make a better garbage collector...'"'' :-) Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at "Perhaps on your way home you will pass someone in the dark, and you will never know it, for they will be from outer space." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 15:54: 4 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 15:54:00 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 0762F37B404; Wed, 13 Dec 2000 15:53:59 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.1/8.11.1) with ESMTP id eBDNplZ04667; Wed, 13 Dec 2000 23:51:47 GMT (envelope-from brian@lan.awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.1/8.11.1) with ESMTP id eBDNtJU70418; Wed, 13 Dec 2000 23:55:19 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200012132355.eBDNtJU70418@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Tony Finch Cc: Brian Somers , Alfred Perlstein , arch@FreeBSD.ORG, net@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: patch to cleanup inflight desciptor handling. In-Reply-To: Message from Tony Finch of "Wed, 13 Dec 2000 22:57:53 GMT." <20001213225753.B30050@hand.dotat.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Dec 2000 23:55:19 +0000 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Brian Somers wrote: > > > >Hmm, the last time i looked at this, I believe the whole thing was > >dealt with by not increasing the file descriptor reference count > >when it was put in the message header. If process A closed the > >descriptor before process B actually recvmsg()d it, it would be > >EBADF. The recvmsg() actually incremented the reference count. > > But it has always been documented behaviour that the receiving process > gets a valid descriptor even if the sender closes it directly after > sendmsging it. If this was not the case then descriptor handoff would > require an "ok" reply from the receiving process before the sender > could close it, which is a pain. > > Hmm, the only references for this I can think of are Stevens and the > red & black daemon books, but I'm sure I've read a good discussion of > it somewhere else. I've just looked back through my archives... the problem I'm thinking of was a different problem - where the descriptor passed was the only descriptor open for a tty whose pgrp was that of process A. A passed the descriptor to B and then exited at which point the tty (correctly) revoked all it's remaining descriptors (the one en-route or in process B). There's no way to avoid this - except by having A fork(), the child close the descriptor and continue where it left off and the parent pause() waiting for a signal from B to tell it that it's finished with that tty. This is why I implemented ``enable keep-session'' :-) > Tony. > -- > f.a.n.finch fanf@covalent.net dot@dotat.at > "And remember my friend, future events such > as these will affect you in the future." Cheers. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 17:25:48 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 17:25:44 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 0181A37B698; Wed, 13 Dec 2000 17:25:44 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eBE1Pbi89951; Wed, 13 Dec 2000 17:25:37 -0800 (PST) (envelope-from dillon) Date: Wed, 13 Dec 2000 17:25:37 -0800 (PST) From: Matt Dillon Message-Id: <200012140125.eBE1Pbi89951@earth.backplane.com> To: Alfred Perlstein Cc: Kirk McKusick , arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: patch to cleanup inflight desciptor handling. References: <200012131852.KAA17423@beastie.mckusick.com> <200012132106.eBDL6Sg86570@earth.backplane.com> <20001213141917.Q16205@fw.wintelcom.net> <20001213145341.S16205@fw.wintelcom.net> <20001213153649.T16205@fw.wintelcom.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :I guess the gc has to stay. : :dammit. :) : :My apologies for wasting everyone's time here. : :-- :-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] No waste at all, Alfred, the file descriptor passing code had been broken for over 10 years precisely because of its complexity. Rewriting the GC to be more efficient essentially requires using deep graph theory to locate isolated loops of arbitrary complexity. p.s. many object oriented language garbage collectors have the same problem. create object A, create object B, A references B, B references A, drop A, drop B. A and B still have references and don't get cleaned up. Fun. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 17:30:19 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 17:30:17 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id B61F537B402; Wed, 13 Dec 2000 17:30:17 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1098) id 528A52B28E; Wed, 13 Dec 2000 19:30:14 -0600 (CST) Date: Wed, 13 Dec 2000 19:30:14 -0600 From: Bill Fumerola To: "Richard A. Steenbergen" Cc: Alfred Perlstein , Bosko Milekic , freebsd-net@FreeBSD.ORG, green@FreeBSD.ORG Subject: Re: Ratelimint Enhancement patch (Please Review One Last Time!) Message-ID: <20001213193014.J72273@elvis.mu.org> References: <20001213112935.K16205@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ras@e-gerbil.net on Wed, Dec 13, 2000 at 02:42:53PM -0500 X-Operating-System: FreeBSD 4.2-FEARSOME-20001103 i386 Sender: billf@elvis.mu.org Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Dec 13, 2000 at 02:42:53PM -0500, Richard A. Steenbergen wrote: > It could just as easily be a SYN flood against a single port... or a large > number of clients trying to connected to your crashed web server... :P Or > it could just as easily be an ack flood against a port without a listener > and be showing up in the "not the ack flood" counter. Exactly. Bikeshedding the millions of possible reasons the queue/ratelimit was triggered is silly. Bosko, please change the descriptions to something very generic before committing them ("ratelimiting TCP RST packets: x/y pps" or something) -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 17:31: 9 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 17:31:05 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 274D037B402; Wed, 13 Dec 2000 17:31:05 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBE1V4611720; Wed, 13 Dec 2000 17:31:04 -0800 (PST) Date: Wed, 13 Dec 2000 17:31:04 -0800 From: Alfred Perlstein To: Matt Dillon Cc: Kirk McKusick , arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: patch to cleanup inflight desciptor handling. Message-ID: <20001213173103.B16205@fw.wintelcom.net> References: <200012131852.KAA17423@beastie.mckusick.com> <200012132106.eBDL6Sg86570@earth.backplane.com> <20001213141917.Q16205@fw.wintelcom.net> <20001213145341.S16205@fw.wintelcom.net> <20001213153649.T16205@fw.wintelcom.net> <200012140125.eBE1Pbi89951@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200012140125.eBE1Pbi89951@earth.backplane.com>; from dillon@earth.backplane.com on Wed, Dec 13, 2000 at 05:25:37PM -0800 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Matt Dillon [001213 17:25] wrote: > > :I guess the gc has to stay. > : > :dammit. :) > : > :My apologies for wasting everyone's time here. > : > :-- > :-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > > No waste at all, Alfred, the file descriptor passing code had been > broken for over 10 years precisely because of its complexity. Rewriting > the GC to be more efficient essentially requires using deep graph theory > to locate isolated loops of arbitrary complexity. > > p.s. many object oriented language garbage collectors have the same > problem. create object A, create object B, A references B, B references A, > drop A, drop B. A and B still have references and don't get cleaned up. > Fun. Are you saying the code in place is broken? If so I'll spend some time looking at it and the Linux implementation to figure if at least one of us gets it right and try to find some sort of solution. Obviously the easiest way would be to disallow passing of any descriptors that have descriptors in thier socketbuffers. Since almost no one uses this code, and I hardly see a reason for allowing that type of operation (passing af_unix fds with fds in flight) it might be a good idea to just disallow that sort of operation. It would definetly simplify and probably speed up the code. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 17:43:21 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 17:43:18 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id EA65F37B698; Wed, 13 Dec 2000 17:43:17 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eBE1hCx90268; Wed, 13 Dec 2000 17:43:12 -0800 (PST) (envelope-from dillon) Date: Wed, 13 Dec 2000 17:43:12 -0800 (PST) From: Matt Dillon Message-Id: <200012140143.eBE1hCx90268@earth.backplane.com> To: Alfred Perlstein Cc: Kirk McKusick , arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: patch to cleanup inflight desciptor handling. References: <200012131852.KAA17423@beastie.mckusick.com> <200012132106.eBDL6Sg86570@earth.backplane.com> <20001213141917.Q16205@fw.wintelcom.net> <20001213145341.S16205@fw.wintelcom.net> <20001213153649.T16205@fw.wintelcom.net> <200012140125.eBE1Pbi89951@earth.backplane.com> <20001213173103.B16205@fw.wintelcom.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> No waste at all, Alfred, the file descriptor passing code had been : :Are you saying the code in place is broken? If so I'll spend some :time looking at it and the Linux implementation to figure if at :least one of us gets it right and try to find some sort of solution. No, *had*, not *has*. It isn't broken, just inefficient in certain cases due to the brute-force GC. :Obviously the easiest way would be to disallow passing of any :descriptors that have descriptors in thier socketbuffers. : :Since almost no one uses this code, and I hardly see a reason for :allowing that type of operation (passing af_unix fds with fds in :flight) it might be a good idea to just disallow that sort of :operation. : :It would definetly simplify and probably speed up the code. There's no reason to disallow that. Besides, any socket can be listen()'d after having been queued, so you aren't really preventing anything. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 18:34:37 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 18:34:36 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id E7CEA37B698 for ; Wed, 13 Dec 2000 18:34:35 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G5J00LCXDTF1M@falla.videotron.net> for freebsd-net@FreeBSD.ORG; Wed, 13 Dec 2000 21:34:28 -0500 (EST) Date: Wed, 13 Dec 2000 21:35:40 -0500 (EST) From: Bosko Milekic Subject: Re: Ratelimint Enhancement patch (Please Review One Last Time!) In-reply-to: <20001213193014.J72273@elvis.mu.org> To: Bill Fumerola Cc: freebsd-net@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 13 Dec 2000, Bill Fumerola wrote: > On Wed, Dec 13, 2000 at 02:42:53PM -0500, Richard A. Steenbergen wrote: > > > It could just as easily be a SYN flood against a single port... or a large > > number of clients trying to connected to your crashed web server... :P Or > > it could just as easily be an ack flood against a port without a listener > > and be showing up in the "not the ack flood" counter. > > Exactly. Bikeshedding the millions of possible reasons the queue/ratelimit > was triggered is silly. > > Bosko, please change the descriptions to something very generic before > committing them ("ratelimiting TCP RST packets: x/y pps" or something) Mike said he would do it and re-post the diff. > -- > Bill Fumerola - security yahoo / Yahoo! inc. > - fumerola@yahoo-inc.com / billf@FreeBSD.org Later, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 21:47:57 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 21:47:52 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id B10B037B698; Wed, 13 Dec 2000 21:47:52 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eBE5lda91759; Wed, 13 Dec 2000 21:47:39 -0800 (PST) (envelope-from dillon) Date: Wed, 13 Dec 2000 21:47:39 -0800 (PST) From: Matt Dillon Message-Id: <200012140547.eBE5lda91759@earth.backplane.com> To: Brian Somers Cc: Alfred Perlstein , arch@FreeBSD.ORG, net@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: patch to cleanup inflight desciptor handling. References: <200012132124.eBDLOBU68538@hak.lan.Awfulhak.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :Hmm, the last time i looked at this, I believe the whole thing was :dealt with by not increasing the file descriptor reference count :when it was put in the message header. If process A closed the :descriptor before process B actually recvmsg()d it, it would be :EBADF. The recvmsg() actually incremented the reference count. : :I always assumed that this was a result of not wanting to have any :funny garbage collecting code ? : :Of course looking at the code now, it increases fp->f_count in :unp_internalize(), so maybe I was on drugs then.... Yes, you were on drugs :-) The moment the descriptor is queued to the socket, the ref count is bumped. It's really a pointer to the underlying file that is queued (and whos ref count is bumped), not the descriptor number. :Assuming I wasn't on drugs (maybe the behaviour was changed - cvs :annotate suggests some activity around March 9, but that was the :file*/int alignment stuff), I think it would be valid to go back :to the old behaviour (not increasing f_count and letting the original :owner actually close the descriptor while f_msgcount != 0). : :Does any of this make sense ? Or am I just describing a different :case (where process B doesn't exit) ? Well, it sort of makes sense, but only in a very twisted fashion :-). sendmsg semantics are that once you queue the descriptor, you can indeed close() it without destroying the queued entity. Think about it... if this were not the case you would be forced to synchronize with the receiving process prior to closing the descriptor on your end to guarentee its validity on the receiving end, which would be a non-trivial piece of userland programming. If we did have those semantics then you could in fact throw the in-flight message away when the sending process went away, but you would have to implement a secondary ref count to prevent the system from throwing away the underlying file until you could clear the message(s). We have *NEVER* had those semantics nor would we ever want those semantics. Even if it were legal (which it isn't), it makes the user-level programming too complex and too fragile. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 23:27:44 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 23:27:40 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 2E17537B400; Wed, 13 Dec 2000 23:27:40 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.15 #3) id 146Snh-00003b-00; Thu, 14 Dec 2000 07:27:37 +0000 Date: Thu, 14 Dec 2000 07:27:37 +0000 From: Tony Finch To: Matt Dillon Cc: Alfred Perlstein , Kirk McKusick , arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: patch to cleanup inflight desciptor handling. Message-ID: <20001214072737.A92196@hand.dotat.at> References: <200012131852.KAA17423@beastie.mckusick.com> <200012132106.eBDL6Sg86570@earth.backplane.com> <20001213141917.Q16205@fw.wintelcom.net> <20001213145341.S16205@fw.wintelcom.net> <20001213153649.T16205@fw.wintelcom.net> <200012140125.eBE1Pbi89951@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200012140125.eBE1Pbi89951@earth.backplane.com> Organization: Covalent Technologies, Inc Sender: fanf@dotat.at Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matt Dillon wrote: > > No waste at all, Alfred, the file descriptor passing code had been > broken for over 10 years precisely because of its complexity. Rewriting > the GC to be more efficient essentially requires using deep graph theory > to locate isolated loops of arbitrary complexity. Most efficient GCers don't involve much graph theory (the notable exception is concurrent collectors); instead they rely on various strategies to drastically reduce the proportion of the arena that they need to examine in most GC runs. In principle mark-sweep collectors are as simple as they get, but unp_gc suffers from the interaction with refcounting. You can use the idea of scanning less of the arena to improve unp_gc as follows. I suggest that you keep two additional lists: one of open unix domain sockets, and one of in-flight sockets. Instead of the existing breadth-first search of the whole file table at the start of unp_gc, it should first clear the mark on each descriptor on the in-flight list, then do a depth-first search of all the descriptors reachable from the unix domain sockets list, marking each one. The loop after the big comment in unp_gc should then scan the in-flight list looking for unmarked descriptors instead of the whole file table. The descriptor freeing loops stay as they are now. I think this should solve the problem at hand, i.e. a lock being held on an important resource while something complicated is being done; instead you would hold locks on two much less important lists (the unix domain list and the in-flight list). > p.s. many object oriented language garbage collectors have the same > problem. create object A, create object B, A references B, B references A, > drop A, drop B. A and B still have references and don't get cleaned up. > Fun. Most modern GCers don't use reference counting partly for that reason, and partly because the overhead of maintaining reference counts is too great. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at "Well, as long as they can think we'll have our problems. But those whom we're using cannot think." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 13 23:34: 2 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 23:33:59 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id AA9D137B400 for ; Wed, 13 Dec 2000 23:33:59 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1098) id 3FFF82B2B6; Thu, 14 Dec 2000 01:33:54 -0600 (CST) Date: Thu, 14 Dec 2000 01:33:54 -0600 From: Bill Fumerola To: Bosko Milekic Cc: freebsd-net@FreeBSD.ORG Subject: Re: Ratelimint Enhancement patch (Please Review One Last Time!) Message-ID: <20001214013354.M72273@elvis.mu.org> References: <20001213193014.J72273@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bmilekic@technokratis.com on Wed, Dec 13, 2000 at 09:35:40PM -0500 X-Operating-System: FreeBSD 4.2-FEARSOME-20001103 i386 Sender: billf@elvis.mu.org Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Dec 13, 2000 at 09:35:40PM -0500, Bosko Milekic wrote: > > Bosko, please change the descriptions to something very generic before > > committing them ("ratelimiting TCP RST packets: x/y pps" or something) > > Mike said he would do it and re-post the diff. Excellent. -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 2:48:46 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 02:48:44 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mail.ruhr.de (in-ruhr3.ruhr.de [212.23.134.2]) by hub.freebsd.org (Postfix) with SMTP id 45FBE37B404 for ; Thu, 14 Dec 2000 02:48:43 -0800 (PST) Received: (qmail 30913 invoked by alias); 14 Dec 2000 10:49:04 -0000 Received: (from ue@localhost) by nathan.ruhr.de (8.11.0/8.11.0) id eBEAmhH80461 for freebsd-net@freebsd.org; Thu, 14 Dec 2000 11:48:43 +0100 (CET) (envelope-from ue) Date: Thu, 14 Dec 2000 11:48:43 +0100 From: Udo Erdelhoff To: freebsd-net@freebsd.org Subject: Strange fragmentation needed message Message-ID: <20001214114843.A85041@nathan.ruhr.de> Mail-Followup-To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I've been experiencing problems with TCP connections. The symptoms are: - I can't upload large (>5 KByte) files with ftp, the client reports "stalled" at file position 19456; the server receives only the first 1024 Bytes of the file. Downloads work just fine. - Sending mail (uucp-over-ip) takes a long time. uucico complains about a timeout, closes the connection, calls again and restarts after 1024 bytes (2048 for the third connection, etc). - cvsup fails with Establishing multiplexed-mode data connection Running Detailer failed: Network read failure: Connection timed out Will retry at ... Aborting and restarting cvsup will eventually result in a successfull run. The box runs -current (PRE_SMPNG), the connection to the outside is an ADSL line (768/128). I'm using ppp with the assorted netgraph modules and ipfw&natd for NAT. Using ppp -nat instead doesn't help. I've had to ignore the problems for some time due to RL. I've tried to analyse the network traffic and found the following messages with tcpdump -ni tun0 11:36:33.213801 212.185.239.152 > 212.185.239.152: icmp: 212.185.239.152 unreachable - need to frag (mtu 1480) 212.185.239.152 being *my* IP-address. I don't understand what's going on. Traffic for my machine shouldn't be routed into the tunnel (i.e. ppp should add a route to 127.0.0.1 for $MYADDR). And I don't understand the reason for them, either. What's going on? /s/Udo -- >Every program evolves until it is capable of sending email. Except Microsoft Exchange To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 4:16:53 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 04:16:48 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 9A4A937B402; Thu, 14 Dec 2000 04:16:43 -0800 (PST) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id EAA00423; Thu, 14 Dec 2000 04:15:54 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id EAA54566; Thu, 14 Dec 2000 04:15:53 -0800 (PST) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id EAA25399; Thu, 14 Dec 2000 04:15:53 -0800 (PST) From: Don Lewis Message-Id: <200012141215.EAA25399@salsa.gv.tsc.tdk.com> Date: Thu, 14 Dec 2000 04:15:53 -0800 In-Reply-To: References: X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: "Richard A. Steenbergen" , Alfred Perlstein Subject: Re: Ratelimint Enhancement patch (Please Review One Last Time!) Cc: Bosko Milekic , freebsd-net@FreeBSD.ORG, green@FreeBSD.ORG Sender: gdonl@tsc.tdk.com Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Dec 13, 2:42pm, "Richard A. Steenbergen" wrote: } Subject: Re: Ratelimint Enhancement patch (Please Review One Last Time!) } On Wed, 13 Dec 2000, Alfred Perlstein wrote: } > Suppressing outgoing RST due to high rate of connections on an unopen } > port (possible portscan): 202/200 pps } } It could just as easily be a SYN flood against a single port... or a large } number of clients trying to connected to your crashed web server... :P Or } it could just as easily be an ack flood against a port without a listener } and be showing up in the "not the ack flood" counter. } } Attaching motives and trying to play intrusion detection pattern analysis } games without complete information is dangerous, and none of these } routines qualify as advanced enough to make any such determination. IMHO } break it down by "RST from ports with or without a listener" (or open } port, whatever floats the boat) and be done with it. The major goal of } this code would seem to be to provide simple but fairly useful protection } against common attacks out of the box, not to provide analysis of the } attacks (since no useful analysis can be performed without looking further } anyways). I think there are three interesting cases: RSTs resulting from SYN packets sent to non-listening ports. This could be a SYN flood, SYN scan, crashed web server with a lot of clients banging on it, etc. RSTs generated by other packets because there is no matching PCB This is probably an ACK flood or ACK scan. RSTs generated by the LAND DoS fixes. I think this really deserves it's now quota in order to prevent a LAND DoS attack from being sucessful just because we hit the RST limit. and maybe an "other" category. Since SYN and ACK floods tend to occur simultaneously, I would be inclined to combine these on one line to decrease the verbosity in the logs. The out of sequence and LAND fix RSTs are also related, the main difference being the socket state. Suppressing TCP RST: SYN to bad port 19999/200 pps, no PCB 19999/200 pps Suppressing TCP RST: SYN_RECEIVED sequence 19999/200 pps, other 19999/200 pps To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 6:18:38 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 06:18:32 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id B68C737B404; Thu, 14 Dec 2000 06:18:30 -0800 (PST) Received: from kairo-18.budapest.interware.hu ([195.70.50.82] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 146ZD8-0002OO-00; Thu, 14 Dec 2000 15:18:19 +0100 Sender: julian@FreeBSD.ORG Message-ID: <3A38D684.F241D6B9@elischer.org> Date: Thu, 14 Dec 2000 06:17:40 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Alfred Perlstein Cc: Matt Dillon , Kirk McKusick , arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: patch to cleanup inflight desciptor handling. References: <200012131852.KAA17423@beastie.mckusick.com> <200012132106.eBDL6Sg86570@earth.backplane.com> <20001213141917.Q16205@fw.wintelcom.net> <20001213145341.S16205@fw.wintelcom.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alfred Perlstein wrote: > > * Alfred Perlstein [001213 14:20] wrote: > > * Matt Dillon [001213 13:07] wrote: > > > :I believe that your changes have been sorely needed for many > > > :years. While I would like to see regular mbufs given a callback > > > :mechanism, your present approach of using an mbuf cluster > > > :solves 90% of the problem. > > > : > > > : Kirk McKusick > > > > > > ... Aflred, be careful that you don't break things we only just fixed > > > last year. The descriptor passing code has been broken for many years. > > > > > > I think the reason we have to scan the descriptor list is related to > > > locating isolated self-referential 'loops' with descriptor passing and > > > unix domain sockets and closing them. e.g. when you pass a descriptor > > > for a unix-domain socket through a unix-domain socket, it is possible > > > for the socket descriptors to reference each other and thus never have > > > their ref count drop to 0 even when all associated processes have > > > close()'d. This happens all the time. Be sure you don't break the > > > fix that solves that particular problem. > > > > Ok, I'll see if that can happen. Basically since the reference > > never goes to zero on the socket, the buffers are never forced to > > be flushed/cleared and the mbuf will then never be free'd resulting > > it it leaking itself. Basically a socket hanging there with an > > mbuf referencing itself. > > > > I wonder if Linux fixed/has this problem. > > Ok, my patch has this problem: > > void > parent(int con) > { > int fd; > > fd = open("/tmp/wank", O_RDONLY); > send_fd_withdata(con, con, "wank", 4); > sleep (5); > exit(1); > > } > > void > child(int con) > { > int fd, error; > char buf[100]; > > sleep(5); > get_fd_withdata(con, &fd, buf, sizeof(buf)); > send_fd_withdata(con, fd, "foo", 3); > exit(1); > buf[4] = '\0'; > printf("%s\n", buf); > if ((error = read(fd, buf, sizeof(buf))) < 0) > perror("read"); > buf[sizeof(buf)-1] = '\0'; > printf("%s\n", buf); > > > } > > This causes a leak, I think the trick is to just always call sorflush() > when the pcb is free'd. that's what I was trying to point out to you.... It get's more complicate when you have 2 pipes, and each has the filedescriptors for the other one in it. > > Looking at linux they still are using gc. I'll give this a lot > more thought before resubmitting this idea. > > sorry, > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 6:53:55 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 06:53:52 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from modemcable101.200-201-24.mtl.mc.videotron.ca (modemcable140.61-201-24.mtl.mc.videotron.ca [24.201.61.140]) by hub.freebsd.org (Postfix) with SMTP id 84AF737B400 for ; Thu, 14 Dec 2000 06:53:51 -0800 (PST) Received: (qmail 58316 invoked from network); 14 Dec 2000 14:53:49 -0000 Received: from patrak.local.mindstep.com (HELO PATRAK) (192.168.10.4) by jacuzzi.local.mindstep.com with SMTP; 14 Dec 2000 14:53:49 -0000 From: "Patrick Bihan-Faou" To: Cc: Subject: Re: Strange fragmentation needed message Date: Thu, 14 Dec 2000 09:54:33 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, You probably need to use tcpmssd from the ports (net/tcpmssd) or use the recently added tcpmss option of PPP for you ADSL link. Look in the archive of this list for TCP MSS and ADSL, and you will find all the information you need. You can also look at http://renaud.waldura.com/doc/freebsd-pppoe/ which is a good paper on your problem. (could somebody add that in the man page for ppp or the freebsd handbook ?) Patrick. "Udo Erdelhoff" wrote in message news:<20001214114843.A85041@nathan.ruhr.de>... > Hi, > I've been experiencing problems with TCP connections. The symptoms are: > > - I can't upload large (>5 KByte) files with ftp, the client reports > "stalled" at file position 19456; the server receives only the first > 1024 Bytes of the file. Downloads work just fine. > - Sending mail (uucp-over-ip) takes a long time. uucico complains about a > timeout, closes the connection, calls again and restarts after 1024 bytes > (2048 for the third connection, etc). > - cvsup fails with > Establishing multiplexed-mode data connection > Running > Detailer failed: Network read failure: Connection timed out > Will retry at ... > > Aborting and restarting cvsup will eventually result in a successfull run. > > The box runs -current (PRE_SMPNG), the connection to the outside is an > ADSL line (768/128). I'm using ppp with the assorted netgraph modules > and ipfw&natd for NAT. Using ppp -nat instead doesn't help. > > I've had to ignore the problems for some time due to RL. I've tried to > analyse the network traffic and found the following messages with > tcpdump -ni tun0 > > 11:36:33.213801 212.185.239.152 > 212.185.239.152: icmp: 212.185.239.152 unreachable - need to frag (mtu 1480) > > 212.185.239.152 being *my* IP-address. > > I don't understand what's going on. Traffic for my machine shouldn't > be routed into the tunnel (i.e. ppp should add a route to 127.0.0.1 for > $MYADDR). And I don't understand the reason for them, either. > > What's going on? > > /s/Udo > -- > >Every program evolves until it is capable of sending email. > Except Microsoft Exchange > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 7:26:50 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 07:26:48 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from paprika.michvhf.com (adsl-pool27-80.detroit.mi.ameritech.net [64.108.60.80]) by hub.freebsd.org (Postfix) with SMTP id 02E4537B400 for ; Thu, 14 Dec 2000 07:26:48 -0800 (PST) Received: (qmail 2639 invoked by uid 1001); 14 Dec 2000 15:26:48 -0000 Date: Thu, 14 Dec 2000 10:26:48 -0500 (EST) From: Vince Vielhaber To: Patrick Bihan-Faou Cc: Subject: Re: Strange fragmentation needed message In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 14 Dec 2000, Patrick Bihan-Faou wrote: > Hi, > > You probably need to use tcpmssd from the ports (net/tcpmssd) or use the > recently added tcpmss option of PPP for you ADSL link. How long ago was this added to PPP? Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ========================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 7:30:39 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 07:30:36 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from modemcable101.200-201-24.mtl.mc.videotron.ca (modemcable140.61-201-24.mtl.mc.videotron.ca [24.201.61.140]) by hub.freebsd.org (Postfix) with SMTP id 77DD037B400 for ; Thu, 14 Dec 2000 07:30:32 -0800 (PST) Received: (qmail 59193 invoked from network); 14 Dec 2000 15:30:30 -0000 Received: from patrak.local.mindstep.com (HELO PATRAK) (192.168.10.4) by jacuzzi.local.mindstep.com with SMTP; 14 Dec 2000 15:30:30 -0000 From: "Patrick Bihan-Faou" To: "Vince Vielhaber" Cc: Subject: RE: Strange fragmentation needed message Date: Thu, 14 Dec 2000 10:31:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I think that it was added in the last 2 weeks. It is in the HEAD for sure. It has not been commited in 4-STABLE yet. Patrick. > -----Original Message----- > From: Vince Vielhaber [mailto:vev@michvhf.com] > Sent: Thursday, December 14, 2000 10:27 AM > To: Patrick Bihan-Faou > Cc: freebsd-net@FreeBSD.ORG > Subject: Re: Strange fragmentation needed message > > > On Thu, 14 Dec 2000, Patrick Bihan-Faou wrote: > > > Hi, > > > > You probably need to use tcpmssd from the ports (net/tcpmssd) or use the > > recently added tcpmss option of PPP for you ADSL link. > > How long ago was this added to PPP? > > Vince. > -- > ========================================================================== > Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net > 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking > Online Campground Directory http://www.camping-usa.com > Online Giftshop Superstore http://www.cloudninegifts.com > ========================================================================== > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 7:41:29 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 07:41:27 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from paprika.michvhf.com (adsl-pool27-80.detroit.mi.ameritech.net [64.108.60.80]) by hub.freebsd.org (Postfix) with SMTP id BFE4037B400 for ; Thu, 14 Dec 2000 07:41:26 -0800 (PST) Received: (qmail 2716 invoked by uid 1001); 14 Dec 2000 15:41:25 -0000 Date: Thu, 14 Dec 2000 10:41:25 -0500 (EST) From: Vince Vielhaber To: Patrick Bihan-Faou Cc: Subject: RE: Strange fragmentation needed message In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 14 Dec 2000, Patrick Bihan-Faou wrote: > I think that it was added in the last 2 weeks. It is in the HEAD for sure. > It has not been commited in 4-STABLE yet. Ok, that explains why I didn't see it in 4.2. Thanks! Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ========================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 9:50:22 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 09:50:19 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from ebola.biohz.net (ebola.biohz.net [206.80.1.35]) by hub.freebsd.org (Postfix) with ESMTP id C487037B404 for ; Thu, 14 Dec 2000 09:50:19 -0800 (PST) Received: from flu (localhost [127.0.0.1]) by ebola.biohz.net (Postfix) with SMTP id 161923A3CC; Thu, 14 Dec 2000 09:50:19 -0800 (PST) Message-ID: <003101c065f6$52ddc640$0402010a@biohz.net> From: "Renaud Waldura" To: Cc: "Brian Somers" References: <200011162137.eAGLbYb42529@hak.lan.Awfulhak.org> Subject: Re: PPPoE w/ nat auto fragmentation hack? Date: Thu, 14 Dec 2000 09:50:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm happy to announce this problem has finally found its final solution in ppp version >= 11/28/2000: the new option "tcpmssfixup" (enabled by default!) corrects the outgoing TCP MSS and solves the problem for good. This functionality is strictly identical to what the tcpmssd port does, but it's now included in ppp, so no need to run an external program with divert sockets etc. Right on Brian! And thanks to Ruslan and Julian. Great job guys. ----- Original Message ----- From: Brian Somers To: Renaud Waldura Cc: Brian Somers ; ; Sent: Thursday, November 16, 2000 1:37 PM Subject: Re: PPPoE w/ nat auto fragmentation hack? (use tcpmssd port) > > > ppp will run programs as the user id that invoked ppp rather than > > > using the effective user id (ie, it runs things as *you*, not *root*). > > > > Mmm-mmh. In my case, since ppp is started at boot time, the only user that > > ever invokes it is root, hence the tcpmssd thingy is run as root. As > > confirmed by the multiple "ps" I ran: euid == ruid == svguid == 0. > > > > > > > A good ``first step'' is to run > > > ! sh -c "/usr/local/bin/tcpmssd -p 12345 -i INTERFACE >/tmp/log 2>&1" > > > so that you can get to see any error messages - ppp redirects I/O to > > > > Yup, tried that, here's what I get: > > > > ******************** start *************** > > Wed Nov 15 13:30:12 PST 2000 > > id says: uid=0(root) gid=0(wheel) groups=0(wheel) > > HOME=/ > > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin > > 01001 divert 1234 tcp from any to any out xmit tun0 setup > > > > The rule gets inserted, tcpmssd runs as root, and I feel like a dummy. Any > > other ideas? > > > > Thanks for the help Brian, > > I'm not sure what the problem could be - can you confirm that > everything's seen if you divert everything ? > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 10:30: 0 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 10:29:50 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 6E97937B402; Thu, 14 Dec 2000 10:29:49 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.15 #3) id 146d8N-000Ll1-00; Thu, 14 Dec 2000 18:29:39 +0000 Date: Thu, 14 Dec 2000 18:29:39 +0000 From: Tony Finch To: Matt Dillon Cc: Alfred Perlstein , Kirk McKusick , arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: patch to cleanup inflight desciptor handling. Message-ID: <20001214182939.B92196@hand.dotat.at> References: <200012131852.KAA17423@beastie.mckusick.com> <200012132106.eBDL6Sg86570@earth.backplane.com> <20001213141917.Q16205@fw.wintelcom.net> <20001213145341.S16205@fw.wintelcom.net> <20001213153649.T16205@fw.wintelcom.net> <200012140125.eBE1Pbi89951@earth.backplane.com> <20001214072737.A92196@hand.dotat.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20001214072737.A92196@hand.dotat.at> Organization: Covalent Technologies, Inc Sender: fanf@dotat.at Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Tony Finch wrote: > >Instead of the existing breadth-first search of the whole file table >at the start of unp_gc, it should first clear the mark on each >descriptor on the in-flight list, then do a depth-first search of all >the descriptors reachable from the unix domain sockets list, marking >each one. Actually that isn't right. The order of the search doesn't matter; what is important is that the trick that the existing code uses (with the FDEFER flag and unp_defer) to perform the scan using no additional space won't work: you must use a more conventional scanning algorithm instead. But anyway, I have found a much better algorithm in the garbage collection book [1]. The algorithm you want [2] isn't directly described in the book; instead they explain a lazy variant [3] which has some additional mechanism to delay running the GC in order to amortise the cost, which is not something we want to do here. AFAICT though the core is the same, so I'll describe it in pseudocode below. It scans the theoretical minimum number of file descriptors :-) When closing a unix domain descriptor with descriptors in flight, do this: count_local_refs(fp); find_external_refs(fp); close_unreffed(fp); count_local_refs counts all the references within the graph of fds reachable from the fd we are closing, taking into account loops: [The foreach syntax is an abbreviation for code like lines 1120 to 1150 of uipc_usrreq.c.] count_local_refs(struct file *fp) { if (!(fp->f_flag & FMAYBEFREE)) { fp->f_flag |= FMAYBEFREE; foreach child (in_flight(fp)) { child->f_count--; count_local_refs(child); } } } find_external_refs finds subgraphs that are reachable externally and marks them as such: find_external_refs(struct file *fp) { if (fp->f_flag & FMAYBEFREE) if (fp->f_count) mark_external_refs(fp); else { fp->f_flag |= FREALLYFREE; foreach child (in_flight(fp)) find_external_refs(child); } } mark_external_refs(struct file *fp) { fp->f_flag &= ~FMAYBEFREE; foreach child (in_flight(fp)) { child->f_count++; if (fp->f_flag & FMAYBEFREE) mark_external_refs(child); } } close_unreffed then closes all the unreferenced descriptors. close_unreffed(struct file *fp) { if (fp->f_flag & FREALLYFREE) { fp->f_flag &= ~(FMAYBEFREE|FREALLYFREE); foreach child (in_flight(fp)) close_unreffed(child); /* XXX: here we probably need to set fp->f_count to 1 to avoid a panic */ close(fp); } } There are a few problems with this as I have described it, but I think they are reasonably easily fixed: * The recursive algorithms may overflow the kernel stack so they should be replaced with iterative ones. * The way it fools around with refcounts will cause trouble if any other processes do things with the descriptors that the algorithm is dealing with; perhaps the first pass through the graph should lock all the descriptors to avoid this. * It will fail if it is run concurrently on two overlapping graphs; there should be a mutex around the unix domain socket close code to prevent this happening. * The unix domain socket close code must detect when it is called recursively by this code (i.e. fp->f_flag & REALLYFREE) and avoid calling the gc again recursively. Here are the references. According to someone at the San Francisco Public Library there aren't any copies of Information Processing Letters in the Bay Area, which I find hard to believe since it implies that there aren't any good computer science or academic periodical libraries here. [1] R. E. Jones, R. D. Lins: "Garbage Collection"; Wiley (Chichester, 1996). [2] A. D. Martinez, R. Wachenauzer, R. D. Lins: "Cyclic Reference Counting with Local Mark-Scan"; Information Processing Letters 34:31-35, 1990 [3] R. D. Lins: "Cyclic Reference Counting with Local Mark-Scan"; Information Processing Letters 44(4):215-220, 1992; University of Kent at Canterbury Computing Laboratory Technical Report 75, July 1990. [4] R. D. Lins, M. A. Vasques: University of Kent at Canterbury Computing Laboratory Technical Report 92, August 1991. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at "Because all you of Earth are idiots!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 14: 9:24 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 14:09:20 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 30D7D37B402; Thu, 14 Dec 2000 14:09:19 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.15 #3) id 146gYl-0003CX-00; Thu, 14 Dec 2000 22:09:07 +0000 Date: Thu, 14 Dec 2000 22:09:07 +0000 From: Tony Finch To: Matt Dillon Cc: Alfred Perlstein , Kirk McKusick , arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: patch to cleanup inflight desciptor handling. Message-ID: <20001214220907.I92196@hand.dotat.at> References: <200012131852.KAA17423@beastie.mckusick.com> <200012132106.eBDL6Sg86570@earth.backplane.com> <20001213141917.Q16205@fw.wintelcom.net> <20001213145341.S16205@fw.wintelcom.net> <20001213153649.T16205@fw.wintelcom.net> <200012140125.eBE1Pbi89951@earth.backplane.com> <20001214072737.A92196@hand.dotat.at> <20001214182939.B92196@hand.dotat.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20001214182939.B92196@hand.dotat.at> Organization: Covalent Technologies, Inc Sender: fanf@dotat.at Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Tony Finch wrote: > >R. D. Lins: "Cyclic Reference Counting with Local Mark-Scan"; >Information Processing Letters 44(4):215-220, 1992; University of Kent >at Canterbury Computing Laboratory Technical Report 75, July 1990. http://citeseer.nj.nec.com/lins90cyclic.html Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at "Then they attacked a town. A small town, I'll admit. But nevertheless a town of people. People who died." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 15: 8:51 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 15:08:46 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 4A34E37B400; Thu, 14 Dec 2000 15:08:46 -0800 (PST) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id QAA01598; Thu, 14 Dec 2000 16:03:58 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpdAAAVva4ed; Thu Dec 14 16:03:52 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id QAA15345; Thu, 14 Dec 2000 16:08:36 -0700 (MST) From: Terry Lambert Message-Id: <200012142308.QAA15345@usr08.primenet.com> Subject: Re: patch to cleanup inflight desciptor handling. To: bright@wintelcom.net (Alfred Perlstein) Date: Thu, 14 Dec 2000 23:08:36 +0000 (GMT) Cc: dillon@earth.backplane.com (Matt Dillon), mckusick@mckusick.com (Kirk McKusick), arch@FreeBSD.ORG, net@FreeBSD.ORG In-Reply-To: <20001213141917.Q16205@fw.wintelcom.net> from "Alfred Perlstein" at Dec 13, 2000 02:19:18 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: tlambert@usr08.primenet.com Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Ok, I'll see if that can happen. Basically since the reference > never goes to zero on the socket, the buffers are never forced to > be flushed/cleared and the mbuf will then never be free'd resulting > it it leaking itself. Basically a socket hanging there with an > mbuf referencing itself. > > I wonder if Linux fixed/has this problem. SVR4 and Solaris avoid the problem entirely by ensuring that each reference to a vnode pointer counts as an "open", and the vnode can not be discarded until a 1->0 reference count change (grep for VHOLD/VRELE/VREF in the Solaris headers). This also makes it easier to do kernel level file I/O, since all you need is a vp that has a reference added to it, and you aren't stuck needing a process so that you can have an open file table so you can hold a descriptor reference. A trade off to this approach is that you have to supply the offset on reads and writes, instead of assuming advancement of an automatically maintained f_offset value. That's actually a positive, in my book. So when you are passing the fd, you are actually passing a vp; this is not aproblem, since the semantics are equivalent to "dup", not "dup2", so you don't get to pick your target descriptor, anyway. One real PITA that you will see, if you get into this code at all, is that the lock references don't get reassigned, so they all go away ("POSIX me _harder_!") when the passer does the close, which is probably the wrong thing. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 15:16:41 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 15:16:37 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 74DAE37B400; Thu, 14 Dec 2000 15:16:37 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.15 #3) id 146hbx-0005Rn-00; Thu, 14 Dec 2000 23:16:29 +0000 Date: Thu, 14 Dec 2000 23:16:29 +0000 From: Tony Finch To: Terry Lambert Cc: Alfred Perlstein , Matt Dillon , Kirk McKusick , arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: patch to cleanup inflight desciptor handling. Message-ID: <20001214231629.K92196@hand.dotat.at> References: <20001213141917.Q16205@fw.wintelcom.net> <200012142308.QAA15345@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200012142308.QAA15345@usr08.primenet.com> Organization: Covalent Technologies, Inc Sender: fanf@dotat.at Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Terry Lambert wrote: > >SVR4 and Solaris avoid the problem entirely by ensuring that >each reference to a vnode pointer counts as an "open", and >the vnode can not be discarded until a 1->0 reference count >change (grep for VHOLD/VRELE/VREF in the Solaris headers). FreeBSD does this too. It doesn't solve the circular reference problem, though (hence the AI Koan). Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at "Then they attacked a town. A small town, I'll admit. But nevertheless a town of people. People who died." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 15:37:32 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 15:37:27 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 356D237B400; Thu, 14 Dec 2000 15:37:27 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id QAA23890; Thu, 14 Dec 2000 16:33:51 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp05.primenet.com, id smtpdAAA2ba4LU; Thu Dec 14 16:33:45 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id QAA15971; Thu, 14 Dec 2000 16:37:16 -0700 (MST) From: Terry Lambert Message-Id: <200012142337.QAA15971@usr08.primenet.com> Subject: Re: patch to cleanup inflight desciptor handling. To: dot@dotat.at (Tony Finch) Date: Thu, 14 Dec 2000 23:37:15 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), bright@wintelcom.net (Alfred Perlstein), dillon@earth.backplane.com (Matt Dillon), mckusick@mckusick.com (Kirk McKusick), arch@FreeBSD.ORG, net@FreeBSD.ORG In-Reply-To: <20001214231629.K92196@hand.dotat.at> from "Tony Finch" at Dec 14, 2000 11:16:29 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: tlambert@usr08.primenet.com Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >SVR4 and Solaris avoid the problem entirely by ensuring that > >each reference to a vnode pointer counts as an "open", and > >the vnode can not be discarded until a 1->0 reference count > >change (grep for VHOLD/VRELE/VREF in the Solaris headers). > > FreeBSD does this too. It doesn't solve the circular reference > problem, though (hence the AI Koan). I think in-progress passes will have their references freed when the receiving end goes away. This still leaves the possibility of a circular reference being passed while being passed until the process exits, but I don't think you need to care about that. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 15:45:45 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 15:45:41 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id F36F937B402; Thu, 14 Dec 2000 15:45:40 -0800 (PST) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id QAA21835; Thu, 14 Dec 2000 16:41:26 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpdAAAduaaFQ; Thu Dec 14 16:41:21 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id QAA16165; Thu, 14 Dec 2000 16:45:27 -0700 (MST) From: Terry Lambert Message-Id: <200012142345.QAA16165@usr08.primenet.com> Subject: Re: patch to cleanup inflight desciptor handling. To: dot@dotat.at (Tony Finch) Date: Thu, 14 Dec 2000 23:45:27 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), bright@wintelcom.net (Alfred Perlstein), dillon@earth.backplane.com (Matt Dillon), mckusick@mckusick.com (Kirk McKusick), arch@FreeBSD.ORG, net@FreeBSD.ORG, dot@dotat.at (Tony Finch) In-Reply-To: <20001214233914.L92196@hand.dotat.at> from "Tony Finch" at Dec 14, 2000 11:39:14 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: tlambert@usr08.primenet.com Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >This still leaves the possibility of a circular reference being > >passed while being passed until the process exits, but I don't > >think you need to care about that. > > That's the whole point of this conversation! I don't think you need to care about it. There are valid reasons for doing the passing, and a core dump of one process in a pair involved in a pass could leave the thing in limbo. But it is resolved on process exit. I don't think you need to be overly concerned about the thing being in limbo, since if both processes exit, it's cleaned up. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 15:52:19 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 15:52:13 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 50BBC37B402; Thu, 14 Dec 2000 15:52:13 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBENldm19603; Thu, 14 Dec 2000 15:47:39 -0800 (PST) Date: Thu, 14 Dec 2000 15:47:39 -0800 From: Alfred Perlstein To: Terry Lambert Cc: Tony Finch , Matt Dillon , Kirk McKusick , arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: patch to cleanup inflight desciptor handling. Message-ID: <20001214154739.A19572@fw.wintelcom.net> References: <20001214233914.L92196@hand.dotat.at> <200012142345.QAA16165@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200012142345.QAA16165@usr08.primenet.com>; from tlambert@primenet.com on Thu, Dec 14, 2000 at 11:45:27PM +0000 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Terry Lambert [001214 15:45] wrote: > > >This still leaves the possibility of a circular reference being > > >passed while being passed until the process exits, but I don't > > >think you need to care about that. > > > > That's the whole point of this conversation! > > I don't think you need to care about it. There are valid reasons > for doing the passing, and a core dump of one process in a pair > involved in a pass could leave the thing in limbo. But it is > resolved on process exit. > > I don't think you need to be overly concerned about the thing > being in limbo, since if both processes exit, it's cleaned up. No it's not: Ok, the problem is you have 3 af_unix pairs all open between 2 processes process B sends 3 over 2 to A process B sends 2 over 3 to A process B send 2 and 3 over 1 to A process B closes 1 2 and 3 A then closes 3 2 and then 1 closing 3 and 2 doesn't cause the socketbuffer to be flushed because they are still self referencing. closing 1 causes the socketbuffer to be flushed, on flushing it comes across 2 and drops a reference but doesn't flush, it then hits 3 and drops a reference but doesn't flush. since 3 references 2 and 2 references 3 and nothing else references 2 or 3, we just leaked 2 and 3. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 16:11:14 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 16:11:10 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id C24EC37B402; Thu, 14 Dec 2000 16:11:09 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eBF0B2R99195; Thu, 14 Dec 2000 16:11:02 -0800 (PST) (envelope-from dillon) Date: Thu, 14 Dec 2000 16:11:02 -0800 (PST) From: Matt Dillon Message-Id: <200012150011.eBF0B2R99195@earth.backplane.com> To: Terry Lambert Cc: dot@dotat.at (Tony Finch), tlambert@primenet.com (Terry Lambert), bright@wintelcom.net (Alfred Perlstein), mckusick@mckusick.com (Kirk McKusick), arch@FreeBSD.ORG, net@FreeBSD.ORG, dot@dotat.at (Tony Finch) Subject: Re: patch to cleanup inflight desciptor handling. References: <200012142345.QAA16165@usr08.primenet.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I think there is some confusion over ref counts here. I'm going to try to be clear: You *cannot* use a 1->0 transition on a ref count to cleanup self referential loops in socket message queues from file descriptor passing. Because no 1->0 transition will ever occur, even if both processes exit. This is because the file underlying the descriptor gets its ref count bumped when the *underyling* file is queued over the socket. We are *not* going to remove the ref count bumping. That's silly. We need to track references on the underlying file no matter who is referencing it.. whether it be a process or a message sitting in a socket queue. We are *not* going create a separate ref count field just to track socket queue references, because this breaks the file descriptor passing semantics... it is perfectly legal for the sending process to go away (exit, crash, whatever) after passing a descriptor prior to the receiving process recvmsg()ing the descriptor. The descriptor is not associated with the receiving process's descriptor resources until the receiving process pulls the message... this is necessary, otherwise the receiving process has no ability to control its file descriptors (descriptors would be able to pop up, at any time, outside of the receiving processes control). We are *not* going to allow the descriptors sitting in isolated loops to leak the system to death by ignoring them. There is no simple solution to the garbage collection problem. That's why the current inefficient, slow, spegetti that is the current GC code is still being used. We may be able to make it more efficient, but short of some genius spending a long time figuring out the perfect solution there aren't going to be any rewrites. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 16:18:48 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 16:18:44 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id BC37B37B402; Thu, 14 Dec 2000 16:18:43 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.15 #3) id 146iZz-0007V7-00; Fri, 15 Dec 2000 00:18:31 +0000 Date: Fri, 15 Dec 2000 00:18:31 +0000 From: Tony Finch To: Matt Dillon Cc: Terry Lambert , Alfred Perlstein , Kirk McKusick , arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: patch to cleanup inflight desciptor handling. Message-ID: <20001215001831.N92196@hand.dotat.at> References: <200012142345.QAA16165@usr08.primenet.com> <200012150011.eBF0B2R99195@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200012150011.eBF0B2R99195@earth.backplane.com> Organization: Covalent Technologies, Inc Sender: fanf@dotat.at Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matt Dillon wrote: > > We are *not* going create a separate ref count field just to track > socket queue references, because this breaks the file descriptor passing > semantics... There is an f_msgcount field already but isn't used for the sort of half-baked hack at the problem which you are railing against :-) > There is no simple solution to the garbage collection problem. That's > why the current inefficient, slow, spegetti that is the current GC code > is still being used. We may be able to make it more efficient, but short > of some genius spending a long time figuring out the perfect solution > there aren't going to be any rewrites. From looking at the GC literature the best known solution to this problem is the one I posted earlier today. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at "If I didn't see it with my own eyes I would never have believed it!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 17: 2:15 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 17:02:08 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 92C9337B402 for ; Thu, 14 Dec 2000 17:02:07 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.1/8.11.1) with ESMTP id eBF0xxZ10931; Fri, 15 Dec 2000 00:59:59 GMT (envelope-from brian@lan.awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.1/8.11.1) with ESMTP id eBF13aU52009; Fri, 15 Dec 2000 01:03:36 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200012150103.eBF13aU52009@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Renaud Waldura" Cc: net@freebsd.org, "Brian Somers" , brian@Awfulhak.org Subject: Re: PPPoE w/ nat auto fragmentation hack? In-Reply-To: Message from "Renaud Waldura" of "Thu, 14 Dec 2000 09:50:18 PST." <003101c065f6$52ddc640$0402010a@biohz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Dec 2000 01:03:36 +0000 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I'm happy to announce this problem has finally found its final solution in > ppp version >= 11/28/2000: the new option "tcpmssfixup" (enabled by > default!) corrects the outgoing TCP MSS and solves the problem for good. > This functionality is strictly identical to what the tcpmssd port does, but > it's now included in ppp, so no need to run an external program with divert > sockets etc. > > Right on Brian! And thanks to Ruslan and Julian. Great job guys. And thank you for taking the time to report things as working :-) > ----- Original Message ----- > From: Brian Somers > To: Renaud Waldura > Cc: Brian Somers ; ; > > Sent: Thursday, November 16, 2000 1:37 PM > Subject: Re: PPPoE w/ nat auto fragmentation hack? (use tcpmssd port) > > > > > > ppp will run programs as the user id that invoked ppp rather than > > > > using the effective user id (ie, it runs things as *you*, not *root*). > > > > > > Mmm-mmh. In my case, since ppp is started at boot time, the only user > that > > > ever invokes it is root, hence the tcpmssd thingy is run as root. As > > > confirmed by the multiple "ps" I ran: euid == ruid == svguid == 0. > > > > > > > > > > A good ``first step'' is to run > > > > ! sh -c "/usr/local/bin/tcpmssd -p 12345 -i INTERFACE >/tmp/log > 2>&1" > > > > so that you can get to see any error messages - ppp redirects I/O to > > > > > > Yup, tried that, here's what I get: > > > > > > ******************** start *************** > > > Wed Nov 15 13:30:12 PST 2000 > > > id says: uid=0(root) gid=0(wheel) groups=0(wheel) > > > HOME=/ > > > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin > > > 01001 divert 1234 tcp from any to any out xmit tun0 setup > > > > > > The rule gets inserted, tcpmssd runs as root, and I feel like a dummy. > Any > > > other ideas? > > > > > > Thanks for the help Brian, > > > > I'm not sure what the problem could be - can you confirm that > > everything's seen if you divert everything ? -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 17:59: 6 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 17:59:05 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from xena.gsicomp.on.ca (cr677933-a.ktchnr1.on.wave.home.com [24.43.230.149]) by hub.freebsd.org (Postfix) with ESMTP id 53F4937B402 for ; Thu, 14 Dec 2000 17:59:04 -0800 (PST) Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.9.3/8.9.3) with SMTP id UAA84841 for ; Thu, 14 Dec 2000 20:59:03 -0500 (EST) (envelope-from matt@gsicomp.on.ca) Message-ID: <002101c0663a$d0270b90$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: References: <200012150103.eBF13aU52009@hak.lan.Awfulhak.org> Subject: Re: PPPoE w/ nat auto fragmentation hack? Date: Thu, 14 Dec 2000 21:00:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I'm happy to announce this problem has finally found its final solution in > > ppp version >= 11/28/2000: the new option "tcpmssfixup" (enabled by > > default!) corrects the outgoing TCP MSS and solves the problem for good. > > This functionality is strictly identical to what the tcpmssd port does, but > > it's now included in ppp, so no need to run an external program with divert > > sockets etc. I've been watching this thread (since when I used to use DSL & PPPoE I used to see this problem, although at the time I didn't know what it was) and am amazed at how everyone's worked together to detect and fix this problem. Now, I'm not trying to play devil's advocate (although that would make me a friend of Chucky, right?) but I'm wondering if user-ppp is the right place to make this change. Isn't the problem specific to PPPoE? If that's the case, then shouldn't it be ng_pppoe that gets updated, so that anything that uses ng_pppoe will have the option of enabling the 'tcpmssfixup' option? -- Matthew Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 19:28:42 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 19:28:40 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from cgaylord.async.vt.edu (e028121.vtacs.vt.edu [63.164.28.121]) by hub.freebsd.org (Postfix) with ESMTP id 48D4937B400 for ; Thu, 14 Dec 2000 19:28:40 -0800 (PST) Received: by cgaylord.async.vt.edu (Postfix, from userid 1000) id 7943C1F9; Thu, 14 Dec 2000 22:28:39 -0500 (EST) Date: Thu, 14 Dec 2000 22:28:39 -0500 From: Clark Gaylord To: freebsd-net@freebsd.org Subject: non-learning bridge for pathological network Message-ID: <20001214222838.B84586@cgaylord.async.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: gaylord@cgaylord.async.vt.edu Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am interested in creating a pathological lab network with the following forwarding rules: - three networks (A,B,C) - packets from A or C are forwarded to B - packets from B are forward to both A and C I was thinking of using BRIDGE+ipfw to create this by hacking bridge.c so that all dsts are UNKNOWN, then filtering via ipfw by deny ip from A to C deny ip from C to A Seems like this would work, but I was wondering what others' thoughts might be on this approach. Perhaps BRIDGE could have a (compile-time?) non-learning flag so that all packets get forwarded as if they are UNKNOWN. Oh, btw, I also want tcpdump to work on any of these interfaces. ;-) Thanks. Clark cgaylord@vt.edu ----- End forwarded message ----- -- Clark K. Gaylord Blacksburg, Virginia USA cgaylord@vt.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 19:44: 8 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 19:44:04 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id C209F37B400 for ; Thu, 14 Dec 2000 19:44:04 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id eBF3i3592156; Thu, 14 Dec 2000 19:44:03 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200012150344.eBF3i3592156@iguana.aciri.org> Subject: Re: non-learning bridge for pathological network In-Reply-To: <20001214222838.B84586@cgaylord.async.vt.edu> from Clark Gaylord at "Dec 14, 2000 10:28:39 pm" To: cgaylord@vt.edu (Clark Gaylord) Date: Thu, 14 Dec 2000 19:44:03 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: rizzo@iguana.aciri.org Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, if you want to use bridging and you know the IPs of the hosts on "networks" A, B, and C (which is what you need to use the 'deny' rules) you do not need to hack bridge.c On the other hand, your solution will not block ARPs and subnet-broadcast packets, so i really think the best solution is to use 3 real subnets for A B and C (i.e. different address ranges), set the machine to act as a router (net.inet.ip.forwarding=1) and block traffic between A and C using the firewall below. No bridging or messing with the kernel involved cheers luigi > I am interested in creating a pathological lab network with the > following forwarding rules: > - three networks (A,B,C) > - packets from A or C are forwarded to B > - packets from B are forward to both A and C > > I was thinking of using BRIDGE+ipfw to create this by hacking > bridge.c so that all dsts are UNKNOWN, then filtering via ipfw by > deny ip from A to C > deny ip from C to A > > Seems like this would work, but I was wondering what others' thoughts > might be on this approach. Perhaps BRIDGE could have a (compile-time?) > non-learning flag so that all packets get forwarded as if they are > UNKNOWN. > > Oh, btw, I also want tcpdump to work on any of these interfaces. ;-) > > Thanks. > Clark > cgaylord@vt.edu > > > ----- End forwarded message ----- > > -- > Clark K. Gaylord > Blacksburg, Virginia USA > cgaylord@vt.edu > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 21:25:20 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 21:25:16 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from cgaylord.async.vt.edu (e028121.vtacs.vt.edu [63.164.28.121]) by hub.freebsd.org (Postfix) with ESMTP id BA44937B400 for ; Thu, 14 Dec 2000 21:25:16 -0800 (PST) Received: by cgaylord.async.vt.edu (Postfix, from userid 1000) id 6E5882E1; Fri, 15 Dec 2000 00:25:15 -0500 (EST) Date: Fri, 15 Dec 2000 00:25:15 -0500 From: Clark Gaylord To: Luigi Rizzo Cc: freebsd-net@freebsd.org Subject: Re: non-learning bridge for pathological network Message-ID: <20001215002514.C84586@cgaylord.async.vt.edu> References: <20001214222838.B84586@cgaylord.async.vt.edu> <200012150344.eBF3i3592156@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200012150344.eBF3i3592156@iguana.aciri.org>; from rizzo@aciri.org on Thu, Dec 14, 2000 at 07:44:03PM -0800 Sender: gaylord@cgaylord.async.vt.edu Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello Luigi -- Thank you for your response. Btw, I've been reading over the bridge code ... many thanks for this valuable resource! The problem with the "just let it be a router" approach is that I want all traffic from B to go to A and C, not just that which is actually intended for said net (yes all can be considered nets). I.e., a packet destined for A should be forwarded to C as well as A. I do not see a way to do this by being a router. OTOH, a non-learning bridge (or pretending the destination is UNKNOWN ... my hack to labotomize the bridge) does this. If there is another way to perform this "forward to multiple interfaces", I'd be happy to hear what you think. The point of clobbering ARPs is an interesting one; I'll have to think about that a bit. I think I can just use static ARP tables for the labs in question. The subnet-broadcast IP packets would still have source address from A, say, so maybe some interface- specific denies, e.g.: deny from A via ifC instead of deny from A to C I still get confused with via. Clark On Thu, Dec 14, 2000 at 07:44:03PM -0800, Luigi Rizzo wrote: > if you want to use bridging and you know the IPs of the hosts on > "networks" A, B, and C (which is what you need to use the 'deny' > rules) you do not need to hack bridge.c > > On the other hand, your solution will not block ARPs and subnet-broadcast > packets, so i really think the best solution is to use 3 real > subnets for A B and C (i.e. different address ranges), set the > machine to act as a router (net.inet.ip.forwarding=1) and block > traffic between A and C using the firewall below. No bridging or > messing with the kernel involved > > cheers > luigi > > > I am interested in creating a pathological lab network with the > > following forwarding rules: > > - three networks (A,B,C) > > - packets from A or C are forwarded to B > > - packets from B are forward to both A and C > > > > I was thinking of using BRIDGE+ipfw to create this by hacking > > bridge.c so that all dsts are UNKNOWN, then filtering via ipfw by > > deny ip from A to C > > deny ip from C to A > > > > Seems like this would work, but I was wondering what others' thoughts > > might be on this approach. Perhaps BRIDGE could have a (compile-time?) > > non-learning flag so that all packets get forwarded as if they are > > UNKNOWN. > > > > Oh, btw, I also want tcpdump to work on any of these interfaces. ;-) > > > > Thanks. > > Clark > > cgaylord@vt.edu > > > > > > ----- End forwarded message ----- > > > > -- > > Clark K. Gaylord > > Blacksburg, Virginia USA > > cgaylord@vt.edu > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > -- Clark K. Gaylord Blacksburg, Virginia USA cgaylord@vt.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 21:55:13 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 21:55:11 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-c.mdsn1.wi.home.com [24.183.3.139]) by hub.freebsd.org (Postfix) with ESMTP id 946A837B404 for ; Thu, 14 Dec 2000 21:55:10 -0800 (PST) Received: (qmail 16555 invoked by uid 1000); 15 Dec 2000 05:55:08 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 15 Dec 2000 05:55:08 -0000 Date: Thu, 14 Dec 2000 23:55:08 -0600 (CST) From: Mike Silbersack To: freebsd-net@freebsd.org Subject: Updated ratelimit patch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ok, I've redone the messages in the ratelimiting patch. They are now as follows: Limiting icmp unreach response from 439 to 200 packets per second Limiting closed port RST response from 283 to 200 packets per second Limiting open port RST response from 18724 to 200 packets per second Limiting icmp ping response from 211 to 200 packets per second Limiting icmp tstamp response from 394 to 200 packets per second No other changes have been made, and the updated patch is available at: http://www.silby.com/patches/ratelimit-enhancement-3.patch Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 22:29:42 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 22:29:40 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id 08E6837B400 for ; Thu, 14 Dec 2000 22:29:40 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G5L00FBNJDETQ@falla.videotron.net> for freebsd-net@FreeBSD.ORG; Fri, 15 Dec 2000 01:29:38 -0500 (EST) Date: Fri, 15 Dec 2000 01:30:53 -0500 (EST) From: Bosko Milekic Subject: Re: Updated ratelimit patch In-reply-to: To: Mike Silbersack Cc: freebsd-net@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Looks good to me, I'll commit this within the next 24 hours unless someone complains with reason. Thanks Mike. On Thu, 14 Dec 2000, Mike Silbersack wrote: > > Ok, I've redone the messages in the ratelimiting patch. They are now as > follows: > > Limiting icmp unreach response from 439 to 200 packets per second > Limiting closed port RST response from 283 to 200 packets per second > Limiting open port RST response from 18724 to 200 packets per second > Limiting icmp ping response from 211 to 200 packets per second > Limiting icmp tstamp response from 394 to 200 packets per second > > No other changes have been made, and the updated patch is available at: > http://www.silby.com/patches/ratelimit-enhancement-3.patch > > Mike "Silby" Silbersack Regards, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 22:45:20 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 22:45:17 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from modemcable101.200-201-24.mtl.mc.videotron.ca (modemcable140.61-201-24.mtl.mc.videotron.ca [24.201.61.140]) by hub.freebsd.org (Postfix) with SMTP id 3FA6037B400 for ; Thu, 14 Dec 2000 22:45:17 -0800 (PST) Received: (qmail 1504 invoked from network); 15 Dec 2000 06:45:16 -0000 Received: from patrak.local.mindstep.com (HELO PATRAK) (192.168.10.4) by jacuzzi.local.mindstep.com with SMTP; 15 Dec 2000 06:45:16 -0000 From: "Patrick Bihan-Faou" To: Subject: Re: PPPoE w/ nat auto fragmentation hack? Date: Fri, 15 Dec 2000 01:46:06 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! ""Matthew Emmerton"" wrote in message news:<002101c0663a$d0270b90$1200a8c0@gsicomp.on.ca>... > > > I'm happy to announce this problem has finally found its final solution > > > in ppp version >= 11/28/2000: the new option "tcpmssfixup" (enabled by > > > default!) corrects the outgoing TCP MSS and solves the problem for good. > > > This functionality is strictly identical to what the tcpmssd port does, > > > but it's now included in ppp, so no need to run an external program with > > > divert sockets etc. > > I've been watching this thread (since when I used to use DSL & PPPoE I used > to see this problem, although at the time I didn't know what it was) and am > amazed at how everyone's worked together to detect and fix this problem. > > Now, I'm not trying to play devil's advocate (although that would make me a > friend of Chucky, right?) but I'm wondering if user-ppp is the right place > to make this change. Isn't the problem specific to PPPoE? If that's the > case, then shouldn't it be ng_pppoe that gets updated, so that anything that > uses ng_pppoe will have the option of enabling the 'tcpmssfixup' option? Actually this is not specific to PPPoE. PPPoE shows the problem, but any link with "small" MTU and poorly configured routers suffers from this problem. This is why I initially advocated to get the TCP MSS fixup feature in libalias where it made more sense (to me). But this has been ruled out, and my initial patch was moved to the autonomous tcpmssd daemon, which was felt as an adequate solution by everybody. I am happy to see that with this recent change in PPP, we can get away without an external daemon specifically for this (and the problems related to getting it working right). This is a good thing. My main argument for having this in libalias were: - what this "TCP MSS fixup" thing does is really similar to other NAT functions - the purpose of NAT is to make a network look like a single machine, and if it was really a "single" machine, the TCP MSS would be set to the correct (small) value in the first place (which is why you don't see the problem if you connect a windows machine directly to your ADSL link). - we now have 2 implementations of the same functionality: ppp and tcpmssd So anyway to answer your question quickly, this feature does not belong to ng_pppoe. PPP is a much better place for it, libalias would (for me) be even better. Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 14 23: 7:25 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 23:07:23 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 832C737B72E for ; Thu, 14 Dec 2000 23:05:55 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id eBF75qr93086; Thu, 14 Dec 2000 23:05:52 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200012150705.eBF75qr93086@iguana.aciri.org> Subject: Re: non-learning bridge for pathological network In-Reply-To: <20001215002514.C84586@cgaylord.async.vt.edu> from Clark Gaylord at "Dec 15, 2000 0:25:15 am" To: cgaylord@vt.edu (Clark Gaylord) Date: Thu, 14 Dec 2000 23:05:52 -0800 (PST) Cc: rizzo@aciri.org, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: rizzo@iguana.aciri.org Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Thank you for your response. Btw, I've been reading over the > bridge code ... many thanks for this valuable resource! > > The problem with the "just let it be a router" approach is that I > want all traffic from B to go to A and C, not just that which is > actually intended for said net (yes all can be considered nets). the thing is, i do not see much point for doing this (there would be no receivers on the 'wrong' segment), so it would be easier for me to understand what you have in mind if you describe the reason you want to do this. > specific denies, e.g.: > deny from A via ifC > instead of > deny from A to C > > I still get confused with via. 'via' does not work well with bridged packets, as ipfw has no info on the output interface (as there can be more than one, essentially, and ipfw is invoked only once and _before_ the output if is selected). cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 15 3: 8: 4 2000 From owner-freebsd-net@FreeBSD.ORG Fri Dec 15 03:08:02 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 9BBAF37B400 for ; Fri, 15 Dec 2000 03:08:01 -0800 (PST) Received: from monrovia-31.budapest.interware.hu ([195.70.53.223] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 146siV-000246-00; Fri, 15 Dec 2000 12:07:59 +0100 Sender: julian@FreeBSD.ORG Message-ID: <3A39FB67.C26703D5@elischer.org> Date: Fri, 15 Dec 2000 03:07:19 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Matthew Emmerton Cc: freebsd-net@FreeBSD.ORG Subject: Re: PPPoE w/ nat auto fragmentation hack? References: <200012150103.eBF13aU52009@hak.lan.Awfulhak.org> <002101c0663a$d0270b90$1200a8c0@gsicomp.on.ca> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Emmerton wrote: > > > > I'm happy to announce this problem has finally found its final solution > in > > > ppp version >= 11/28/2000: the new option "tcpmssfixup" (enabled by > > > default!) corrects the outgoing TCP MSS and solves the problem for good. > > > This functionality is strictly identical to what the tcpmssd port does, > but > > > it's now included in ppp, so no need to run an external program with > divert > > > sockets etc. > > I've been watching this thread (since when I used to use DSL & PPPoE I used > to see this problem, although at the time I didn't know what it was) and am > amazed at how everyone's worked together to detect and fix this problem. pppoe is the main place this happens NOW but I have used that functionality with good effect to reduce the packet size on transfers through my machine, where MTU discovery doesn't work and there is an unreliable link. In this case, you want small packets, but you have to force the other machines to decide to use them.. > > Now, I'm not trying to play devil's advocate (although that would make me a > friend of Chucky, right?) but I'm wondering if user-ppp is the right place > to make this change. Isn't the problem specific to PPPoE? If that's the > case, then shouldn't it be ng_pppoe that gets updated, so that anything that > uses ng_pppoe will have the option of enabling the 'tcpmssfixup' option? I was wondering this yesterday.. either that or a separate mss-hack node.. but it needs to look into the tcp packets which means it would have to decode the PPP packets and the IP packets as well as the TCP headers, so I think that either we do it in the IP stack (with help from tcp) or ppp is the right place, because it already has access to all the information (for it's packet filters). We COULD make it a function of libNAT as well of course.. :-) > > -- > Matthew Emmerton > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 15 3:10:52 2000 From owner-freebsd-net@FreeBSD.ORG Fri Dec 15 03:10:50 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 71FAF37B400 for ; Fri, 15 Dec 2000 03:10:49 -0800 (PST) Received: from monrovia-31.budapest.interware.hu ([195.70.53.223] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 146slD-0002GV-00; Fri, 15 Dec 2000 12:10:47 +0100 Sender: julian@FreeBSD.ORG Message-ID: <3A39FC10.CD52AB65@elischer.org> Date: Fri, 15 Dec 2000 03:10:08 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Clark Gaylord Cc: freebsd-net@freebsd.org Subject: Re: non-learning bridge for pathological network References: <20001214222838.B84586@cgaylord.async.vt.edu> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Clark Gaylord wrote: > > I am interested in creating a pathological lab network with the > following forwarding rules: > - three networks (A,B,C) > - packets from A or C are forwarded to B > - packets from B are forward to both A and C > > I was thinking of using BRIDGE+ipfw to create this by hacking > bridge.c so that all dsts are UNKNOWN, then filtering via ipfw by > deny ip from A to C > deny ip from C to A > > Seems like this would work, but I was wondering what others' thoughts > might be on this approach. Perhaps BRIDGE could have a (compile-time?) > non-learning flag so that all packets get forwarded as if they are > UNKNOWN. > > Oh, btw, I also want tcpdump to work on any of these interfaces. ;-) > > Thanks. > Clark > cgaylord@vt.edu > > ----- End forwarded message ----- > > -- > Clark K. Gaylord > Blacksburg, Virginia USA > cgaylord@vt.edu > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message use the netgraph bridgeing. (see the ng_bridge man page and the /usr/share/examples/netgraph documents) it can be loaded as modules so if you really want to you can 'hack' up your own ng-bridge module that does whatever you want, and load that instead. of course tcpdump still works too.. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 15 6:24:11 2000 From owner-freebsd-net@FreeBSD.ORG Fri Dec 15 06:24:10 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 9748837B400 for ; Fri, 15 Dec 2000 06:24:09 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id eBFEKT620203; Fri, 15 Dec 2000 08:20:29 -0600 (CST) (envelope-from jlemon) Date: Fri, 15 Dec 2000 08:20:29 -0600 (CST) From: Jonathan Lemon Message-Id: <200012151420.eBFEKT620203@prism.flugsvamp.com> To: silby@silby.com, net@freebsd.org Subject: Re: Updated ratelimit patch X-Newsgroups: local.mail.freebsd-net In-Reply-To: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you write: > >No other changes have been made, and the updated patch is available at: >http://www.silby.com/patches/ratelimit-enhancement-3.patch Looks good to me. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 15 7: 0:29 2000 From owner-freebsd-net@FreeBSD.ORG Fri Dec 15 07:00:26 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from xena.gsicomp.on.ca (cr677933-a.ktchnr1.on.wave.home.com [24.43.230.149]) by hub.freebsd.org (Postfix) with ESMTP id 952A937B400 for ; Fri, 15 Dec 2000 07:00:25 -0800 (PST) Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.9.3/8.9.3) with SMTP id KAA86007; Fri, 15 Dec 2000 10:00:13 -0500 (EST) (envelope-from matt@gsicomp.on.ca) Message-ID: <003f01c066a7$f75135c0$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: "Julian Elischer" , "Patrick Bihan-Faou" Cc: References: <200012150103.eBF13aU52009@hak.lan.Awfulhak.org> <002101c0663a$d0270b90$1200a8c0@gsicomp.on.ca> <3A39FB67.C26703D5@elischer.org> Subject: Re: PPPoE w/ nat auto fragmentation hack? Date: Fri, 15 Dec 2000 10:01:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Matthew Emmerton wrote: > Julian Elischer wrote: > > Now, I'm not trying to play devil's advocate (although that would make me a > > friend of Chucky, right?) but I'm wondering if user-ppp is the right place > > to make this change. Isn't the problem specific to PPPoE? If that's the > > case, then shouldn't it be ng_pppoe that gets updated, so that anything that > > uses ng_pppoe will have the option of enabling the 'tcpmssfixup' option? > > I was wondering this yesterday.. either that or a separate mss-hack node.. but > it needs to look into the tcp packets which means it would have to decode > the PPP packets and the IP packets as well as the TCP headers, so I think > that either we do it in the IP stack (with help from tcp) or ppp is the right > place, because it already has access to all the information (for it's packet > filters). > > We COULD make it a function of libNAT as well of course.. :-) According to Patrick Bihan-Faou, he suggested this a while ago and it was shot down in favour of the tcpmssd solution, which was later merged into user-ppp. If this problem exists with other protocols, or if the solution can be used with other protocols (in certain situations), then it would make sense to have it somewhere central so that we can avoid kludging up each implementation of each protocol that wants to take advantage of it (user-ppp, ng_ppp, etc). With this in mind, it really needs to be a part of the IP stack or libalias, at least. Perhaps now that the ppp folk have given us a nice reference implementation, we can work on integrating it more tightly with the system? -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 15 7:30: 4 2000 From owner-freebsd-net@FreeBSD.ORG Fri Dec 15 07:30:00 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 5772437B402 for ; Fri, 15 Dec 2000 07:29:59 -0800 (PST) Received: from timbuktu-41.budapest.interware.hu ([195.70.51.233] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 146wnu-0002n3-00; Fri, 15 Dec 2000 16:29:51 +0100 Sender: julian@FreeBSD.ORG Message-ID: <3A39FDCB.236A069A@elischer.org> Date: Fri, 15 Dec 2000 03:17:31 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Patrick Bihan-Faou Cc: freebsd-net@FreeBSD.ORG Subject: Re: PPPoE w/ nat auto fragmentation hack? References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Patrick Bihan-Faou wrote: > d > > So anyway to answer your question quickly, this feature does not belong to > ng_pppoe. PPP is a much better place for it, libalias would (for me) be even > better. I would have to agree with this.. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 15 7:43:26 2000 From owner-freebsd-net@FreeBSD.ORG Fri Dec 15 07:43:23 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mail.ruhr.de (in-ruhr3.ruhr.de [212.23.134.2]) by hub.freebsd.org (Postfix) with SMTP id 2C44837B402 for ; Fri, 15 Dec 2000 07:43:23 -0800 (PST) Received: (qmail 31187 invoked by alias); 15 Dec 2000 16:53:08 -0000 Received: (from ue@localhost) by nathan.ruhr.de (8.11.0/8.11.0) id eBFFhmX88463; Fri, 15 Dec 2000 16:43:48 +0100 (CET) (envelope-from ue) Date: Fri, 15 Dec 2000 16:43:48 +0100 From: Udo Erdelhoff To: freebsd-net@FreeBSD.ORG Cc: Patrick Bihan-Faou Subject: Re: Strange fragmentation needed message Message-ID: <20001215164348.E85041@nathan.ruhr.de> Mail-Followup-To: freebsd-net@FreeBSD.ORG, Patrick Bihan-Faou References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from patrick@netzuno.com on Thu, Dec 14, 2000 at 09:54:33AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, On Thu, Dec 14, 2000 at 09:54:33AM -0500, Patrick Bihan-Faou wrote: > You probably need to use tcpmssd from the ports (net/tcpmssd) or use the > recently added tcpmss option of PPP for you ADSL link. no, that's not the cause of the problem and adding tcpmssd to the mix doesn't solve the problem. My normal setup includes tcpmssd and some filter rules in ppp and ipfw, I kicked them to eliminate some possible problem sources. AFAIK, tcpmssd is only needed for connections originating on boxes in your LAN. If the connection originates on the box with the ADSL line, the MSS will be correct. Anyway, this is a capture of an ftp session with tcpmssd: ] mybox.3176 > remote.21: P 38:53(15) ack 51 win 17424 (DF) [tos 0x10] The last part of the put command ] remote.20 > mybox.40699: S 2001469163:2001469163 (0) win 32120 (DF) Incoming connection from the remote box ] 16:00:53.325469 mybox.40699 > remote.20: S 2723319420:2723319420 (0) ack 2001469164 win 17520 (DF) Reply: No, use mss 1452 ] remote.21 > mybox.3176: . ack 53 win 31944 (DF) ] remote.20 > mybox.40699: . ack 1 win 32120 (DF) ] remote.21 > mybox.3176: P 51:106(55) ack 53 win 31944 (DF) ] mybox.40699 > remote.20: P 1:1025(1024) ack 1 win 17520 (DF) [tos 0x8] ] mybox > mybox: icmp: mybox unreachable - need to frag (mtu 1480) ] mybox > mybox: icmp: mybox unreachable - need to frag (mtu 1480) And boom. > You can also look at http://renaud.waldura.com/doc/freebsd-pppoe/ which is a > good paper on your problem. If you can read German, take a look at my homepage, especially at the paper about using T-ISDN-DSL (the ADSL service I'm using) with FreeBSD, especially the chapters about the MSS/MTU problem and the integration of tcpmssd. /s/Udo -- "No boom today. Boom tomorrow. There's always a boom tomorrow" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 15 10:33:49 2000 From owner-freebsd-net@FreeBSD.ORG Fri Dec 15 10:33:47 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from cgaylord.async.vt.edu (e028121.vtacs.vt.edu [63.164.28.121]) by hub.freebsd.org (Postfix) with ESMTP id 34EF537B400 for ; Fri, 15 Dec 2000 10:33:47 -0800 (PST) Received: by cgaylord.async.vt.edu (Postfix, from userid 1000) id 1749A2E1; Fri, 15 Dec 2000 13:33:46 -0500 (EST) Date: Fri, 15 Dec 2000 13:33:31 -0500 From: Clark Gaylord To: Luigi Rizzo Subject: Re: non-learning bridge for pathological network Message-ID: <20001215133331.E84586@cgaylord.async.vt.edu> References: <20001215002514.C84586@cgaylord.async.vt.edu> <200012150705.eBF75qr93086@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200012150705.eBF75qr93086@iguana.aciri.org>; from rizzo@aciri.org on Thu, Dec 14, 2000 at 11:05:52PM -0800 Resent-From: gaylord@cgaylord.async.vt.edu Resent-Date: Fri, 15 Dec 2000 13:33:45 -0500 Resent-To: freebsd-net@freebsd.org Resent-Message-Id: <20001215183346.1749A2E1@cgaylord.async.vt.edu> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Dec 14, 2000 at 11:05:52PM -0800, Luigi Rizzo wrote: > > The problem with the "just let it be a router" approach is that I > > want all traffic from B to go to A and C, not just that which is > > actually intended for said net (yes all can be considered nets). > > the thing is, i do not see much point for doing this (there would > be no receivers on the 'wrong' segment), so it would be easier for me to > understand what you have in mind if you describe the reason you want > to do this. It is to simulate a problem similar to the hidden node problem in wireless LAN. This is a lab situation, not one where we want a "good" network design. You could similarly consider the problem as similar to arbitrary monitoring, port replication, span port, etc. > > specific denies, e.g.: > > deny from A via ifC > > instead of > > deny from A to C > > > > I still get confused with via. > > 'via' does not work well with bridged packets, as ipfw has no > info on the output interface (as there can be more than one, essentially, > and ipfw is invoked only once and _before_ the output if is selected). Ah, yes, I see that now. Hmmm ... that does make it a poser. -- Clark K. Gaylord Blacksburg, Virginia USA cgaylord@vt.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 15 13: 8: 3 2000 From owner-freebsd-net@FreeBSD.ORG Fri Dec 15 13:08:01 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from virtual.sysadmin-inc.com (lists.sysadmin-inc.com [209.16.228.140]) by hub.freebsd.org (Postfix) with ESMTP id 831D437B400 for ; Fri, 15 Dec 2000 13:08:00 -0800 (PST) Received: from wkst ([209.16.228.146]) by virtual.sysadmin-inc.com (8.9.1/8.9.1) with SMTP id QAA29155 for ; Fri, 15 Dec 2000 16:10:55 -0500 Reply-To: From: "Peter Brezny" To: Subject: named in a sand box. Date: Fri, 15 Dec 2000 16:06:57 -0800 Message-ID: <002d01c066f4$1ba7a980$46010a0a@sysadmininc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have a nomenclature ignorance when it comes to the term sandbox. When someone says, "named runs in a sandbox on my machine." Do they mean a) named runs under an unpriviliged user or b) named runs in a chrooted environment or c) both ? In the /etc/namedb/named.conf it says that freebsd runs bind in a sandbox and refers to the named flags in rc.conf, and when you look at those flags in /etc/defults/named.conf all you see is the -u and -g options for the flags, NOT the -t option for running in a chrooted environemnt. This led me to believe that 'sandbox' means unpriviliged user. But when i posed a related question on -questions, someone told me that sandbox = chrooted environment. I also want to know, if you are running named under an unpriviliged user, is it worth the extra trouble to run it chrooted? Thanks for your help. Peter Brezny SysAdmin Services Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 15 13:12: 4 2000 From owner-freebsd-net@FreeBSD.ORG Fri Dec 15 13:12:03 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from xena.gsicomp.on.ca (cr677933-a.ktchnr1.on.wave.home.com [24.43.230.149]) by hub.freebsd.org (Postfix) with ESMTP id 96CAC37B400 for ; Fri, 15 Dec 2000 13:12:02 -0800 (PST) Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.9.3/8.9.3) with SMTP id QAA86751; Fri, 15 Dec 2000 16:11:59 -0500 (EST) (envelope-from matt@gsicomp.on.ca) Message-ID: <000701c066db$e8969eb0$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: , References: <002d01c066f4$1ba7a980$46010a0a@sysadmininc.com> Subject: Re: named in a sand box. Date: Fri, 15 Dec 2000 16:13:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I have a nomenclature ignorance when it comes to the term sandbox. > > When someone says, "named runs in a sandbox on my machine." > > Do they mean > > a) named runs under an unpriviliged user > or > b) named runs in a chrooted environment > or > c) both At one point in time, "sandbox" meant a) as above. However, with the advent of chroot and the security gains that it provides, "sandbox" has been re-defined to mean b) in most cases. Unfortunately, this means that some documentation causes confusion, such as named-related sources you quoted. -- Matthew Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 15 13:20:43 2000 From owner-freebsd-net@FreeBSD.ORG Fri Dec 15 13:20:39 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by hub.freebsd.org (Postfix) with ESMTP id 6A72437B6BE for ; Fri, 15 Dec 2000 13:19:45 -0800 (PST) Received: from holly.calldei.com ([208.191.149.190]) by mta4.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G5M000B7OFU08@mta4.rcsntx.swbell.net> for freebsd-net@FreeBSD.ORG; Fri, 15 Dec 2000 15:16:43 -0600 (CST) Received: (from chris@localhost) by holly.calldei.com (8.9.3/8.9.3) id PAA46685; Fri, 15 Dec 2000 15:16:10 -0600 (CST envelope-from chris) Date: Fri, 15 Dec 2000 15:15:59 -0600 From: Chris Costello Subject: Re: named in a sand box. In-reply-to: <000701c066db$e8969eb0$1200a8c0@gsicomp.on.ca> To: Matthew Emmerton Cc: peter@sysadmin-inc.com, freebsd-net@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <20001215151559.D37756@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i References: <002d01c066f4$1ba7a980$46010a0a@sysadmininc.com> <000701c066db$e8969eb0$1200a8c0@gsicomp.on.ca> Sender: chris@holly.calldei.com Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Friday, December 15, 2000, Matthew Emmerton wrote: > However, with the advent of chroot and the security gains that it provides, > "sandbox" has been re-defined to mean b) in most cases. chroot is not meant as a security mechanism, it was only meant to change the meaning of "/", originally for building a BSD release (/usr/share/doc/papers/jail.* on -CURRENT). Use the jail mechanism if you need to securely make that sort of "sandbox". -- |Chris Costello |Programs: What software used to be, back when we knew how to write it. `---------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 15 14:37:22 2000 From owner-freebsd-net@FreeBSD.ORG Fri Dec 15 14:37:20 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from origin.macomnet.ru (origin.macomnet.ru [195.128.64.12]) by hub.freebsd.org (Postfix) with ESMTP id 4783A37B400 for ; Fri, 15 Dec 2000 14:37:19 -0800 (PST) Received: from news1.macomnet.ru (news1.macomnet.ru [195.128.64.14]) by origin.macomnet.ru (8.9.1/8.9.1) with ESMTP id BAA4500453; Sat, 16 Dec 2000 01:37:09 +0300 (MSK) Date: Sat, 16 Dec 2000 01:37:09 +0300 (MSK) From: Maxim Konovalov To: Peter Brezny Cc: freebsd-net@FreeBSD.ORG Subject: Re: named in a sand box. In-Reply-To: <002d01c066f4$1ba7a980$46010a0a@sysadmininc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, On Fri, 15 Dec 2000, Peter Brezny wrote: > I have a nomenclature ignorance when it comes to the term sandbox. > > When someone says, "named runs in a sandbox on my machine." > > Do they mean > > a) named runs under an unpriviliged user > or > b) named runs in a chrooted environment > or > c) both > > ? *I* mean "both". http://www.psionic.com/papers/dns/dns-openbsd/ HTH > In the /etc/namedb/named.conf it says that freebsd runs bind in a sandbox > and refers to the named flags in rc.conf, and when you look at those flags > in /etc/defults/named.conf all you see is the -u and -g options for the > flags, NOT the -t option for running in a chrooted environemnt. > > This led me to believe that 'sandbox' means unpriviliged user. But when i > posed a related question on -questions, someone told me that sandbox = > chrooted environment. > > I also want to know, if you are running named under an unpriviliged user, is > it worth the extra trouble to run it chrooted? > > Thanks for your help. > > Peter Brezny > SysAdmin Services Inc. - - maxim -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: maxim@macomnet.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Dec 16 3:27:23 2000 From owner-freebsd-net@FreeBSD.ORG Sat Dec 16 03:27:20 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 0F3BC37B402; Sat, 16 Dec 2000 03:27:20 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id DAA23718; Sat, 16 Dec 2000 03:26:35 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda23716; Sat Dec 16 03:26:15 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.1/8.9.1) id eBGBQ9806221; Sat, 16 Dec 2000 03:26:09 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdwP6219; Sat Dec 16 03:25:51 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.1/8.9.1) id eBGBPkP05378; Sat, 16 Dec 2000 03:25:46 -0800 (PST) Message-Id: <200012161125.eBGBPkP05378@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdDU5367; Sat Dec 16 03:24:58 2000 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.2-RELEASE X-Sender: cy To: "Ari Suutari" Cc: freebsd-net@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: IPFW & IPsec tunnel mode In-reply-to: Your message of "Thu, 07 Dec 2000 09:20:40 +0200." <001301c0601e$34cab880$0e05a8c0@intranet.syncrontech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 16 Dec 2000 03:24:57 -0800 Sender: cy@uumail.gov.bc.ca Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <001301c0601e$34cab880$0e05a8c0@intranet.syncrontech.com>, "Ari Suut ari" writes: > However, pipsecd only supports fixed keys and Kame seems more > like the future way to go. Would it be possible to enhance ipfw & kame > to work together better in same way (like having some kind of name for > each tunnel and allowing ipfw rule to use them in similar way as > 'via' is used with interfaces) ? Check the -security archives. This was just discussed about a month ago. In that thread a KAME developer explained why it cannot be accomplished. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Dec 16 11:15:17 2000 From owner-freebsd-net@FreeBSD.ORG Sat Dec 16 11:15:15 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id 4F5EC37B400 for ; Sat, 16 Dec 2000 11:15:15 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G5O00M9NDHB61@falla.videotron.net> for freebsd-net@freebsd.org; Sat, 16 Dec 2000 14:15:12 -0500 (EST) Date: Sat, 16 Dec 2000 14:16:31 -0500 (EST) From: Bosko Milekic Subject: Changing the names of some M_flags To: freebsd-net@freebsd.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, Recently, there was a bikeshed on one of the lists dealing with whether or not to rename M_WAIT and M_DONTWAIT flags to something else that would "communicate more of the Right Thing" to developers considering that for mbuf allocations, M_WAIT may return a NULL pointer in the case where all mbuf resources are depleted and mbuf_wait time has already been spent waiting. The proposed flag names were/are: M_WAIT --> M_TRY_WAIT M_DONTWAIT --> M_DONTBLOCK I have a diff sitting here: http://people.freebsd.org/~bmilekic/m_flag_rnm.diff It's roughly 160K. On one side, personally, I wasn't so pro-the change, as I see it more as a bloat to the repo than anything else. But, I have to admit that some folks have expressed a significant interest in having them changed and with reason, so I agreed to do it. On this same side, it wasn't such a bad thing to do after all as it led me to spot some not so obfuscated and obfuscated (and potentially serious in the future) bugs which I have yet to fix. A good example is people mixing up M_WAIT and M_WAITOK in calls to malloc() which could potentially lead to disaster if we were to alter the values of the flags. On the other side, I personally do not passionately feel the change "needs" to be made. But, as mentionned, if the majority of developers think that it will avoid needless miscommunication, then I have no problem committing it. I don't want to start a bigger bikeshed from this post than it already is. I'd just like to know if anyone has any reasonable objections to having this change happen. Regards, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Dec 16 11:21:34 2000 From owner-freebsd-net@FreeBSD.ORG Sat Dec 16 11:21:32 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 7400137B400 for ; Sat, 16 Dec 2000 11:21:32 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBGJLU928778; Sat, 16 Dec 2000 11:21:30 -0800 (PST) Date: Sat, 16 Dec 2000 11:21:30 -0800 From: Alfred Perlstein To: Bosko Milekic Cc: freebsd-net@FreeBSD.ORG Subject: Re: Changing the names of some M_flags Message-ID: <20001216112130.Y19572@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bmilekic@technokratis.com on Sat, Dec 16, 2000 at 02:16:31PM -0500 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Bosko Milekic [001216 11:15] wrote: > > Hello, > > Recently, there was a bikeshed on one of the lists dealing with > whether or not to rename M_WAIT and M_DONTWAIT flags to something else > that would "communicate more of the Right Thing" to developers > considering that for mbuf allocations, M_WAIT may return a NULL pointer > in the case where all mbuf resources are depleted and mbuf_wait time has > already been spent waiting. > > The proposed flag names were/are: > > M_WAIT --> M_TRY_WAIT > M_DONTWAIT --> M_DONTBLOCK > I think M_DONTWAIT is fine as it was, and M_TRYWAIT instead of M_TRY_WAIT. Leaving it as M_DONTWAIT should reduce the delta by quite a bit and M_TRYWAIT vs M_TRY_WAIT because you have M_DONTWAIT/M_DONTBLOCK. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Dec 16 11:34:31 2000 From owner-freebsd-net@FreeBSD.ORG Sat Dec 16 11:34:29 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id 37BD937B400 for ; Sat, 16 Dec 2000 11:34:29 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G5O00GFLEDB85@field.videotron.net> for freebsd-net@FreeBSD.ORG; Sat, 16 Dec 2000 14:34:23 -0500 (EST) Date: Sat, 16 Dec 2000 14:35:42 -0500 (EST) From: Bosko Milekic Subject: Re: Changing the names of some M_flags In-reply-to: <20001216112130.Y19572@fw.wintelcom.net> To: Alfred Perlstein Cc: freebsd-net@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 16 Dec 2000, Alfred Perlstein wrote: > I think M_DONTWAIT is fine as it was, and M_TRYWAIT instead of M_TRY_WAIT. > > Leaving it as M_DONTWAIT should reduce the delta by quite a bit and > M_TRYWAIT vs M_TRY_WAIT because you have M_DONTWAIT/M_DONTBLOCK. > > -Alfred I agree. Anyone else before I re-roll? :-) Cheers, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Dec 16 11:38:27 2000 From owner-freebsd-net@FreeBSD.ORG Sat Dec 16 11:38:25 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 1C04137B400 for ; Sat, 16 Dec 2000 11:38:25 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id eBGJYdj75335; Sat, 16 Dec 2000 13:34:39 -0600 (CST) (envelope-from jlemon) Date: Sat, 16 Dec 2000 13:34:39 -0600 (CST) From: Jonathan Lemon Message-Id: <200012161934.eBGJYdj75335@prism.flugsvamp.com> To: bmilekic@technokratis.com, net@freebsd.org Subject: Re: Changing the names of some M_flags X-Newsgroups: local.mail.freebsd-net In-Reply-To: References: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you write: > >On Sat, 16 Dec 2000, Alfred Perlstein wrote: > >> I think M_DONTWAIT is fine as it was, and M_TRYWAIT instead of M_TRY_WAIT. >> >> Leaving it as M_DONTWAIT should reduce the delta by quite a bit and >> M_TRYWAIT vs M_TRY_WAIT because you have M_DONTWAIT/M_DONTBLOCK. >> >> -Alfred > > I agree. Anyone else before I re-roll? :-) I second Alfred's suggestion. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Dec 16 11:45:53 2000 From owner-freebsd-net@FreeBSD.ORG Sat Dec 16 11:45:51 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 3ABC837B400 for ; Sat, 16 Dec 2000 11:45:51 -0800 (PST) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.1/8.11.0) with ESMTP id eBGJjh507797; Sat, 16 Dec 2000 14:45:47 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200012161945.eBGJjh507797@whizzo.transsys.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jonathan Lemon Cc: bmilekic@technokratis.com, net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: Changing the names of some M_flags References: <200012161934.eBGJYdj75335@prism.flugsvamp.com> In-reply-to: Your message of "Sat, 16 Dec 2000 13:34:39 CST." <200012161934.eBGJYdj75335@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 16 Dec 2000 14:45:43 -0500 Sender: louie@TransSys.COM Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > In article you write: > > > >On Sat, 16 Dec 2000, Alfred Perlstein wrote: > > > >> I think M_DONTWAIT is fine as it was, and M_TRYWAIT instead of M_TRY_WAIT. > >> > >> Leaving it as M_DONTWAIT should reduce the delta by quite a bit and > >> M_TRYWAIT vs M_TRY_WAIT because you have M_DONTWAIT/M_DONTBLOCK. > >> > >> -Alfred > > > > I agree. Anyone else before I re-roll? :-) > > I second Alfred's suggestion. Is this just going to make portablity between the various *BSD kernels more difficult for what's essentially a cosmetic change? I'm thinking of things like KAME, ALTQ, etc. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Dec 16 11:53:33 2000 From owner-freebsd-net@FreeBSD.ORG Sat Dec 16 11:53:31 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 4C04137B400 for ; Sat, 16 Dec 2000 11:53:31 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBGJrKM29548; Sat, 16 Dec 2000 11:53:20 -0800 (PST) Date: Sat, 16 Dec 2000 11:53:20 -0800 From: Alfred Perlstein To: "Louis A. Mamakos" Cc: Jonathan Lemon , bmilekic@technokratis.com, net@FreeBSD.ORG Subject: Re: Changing the names of some M_flags Message-ID: <20001216115319.Z19572@fw.wintelcom.net> References: <200012161934.eBGJYdj75335@prism.flugsvamp.com> <200012161945.eBGJjh507797@whizzo.transsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200012161945.eBGJjh507797@whizzo.transsys.com>; from louie@TransSys.COM on Sat, Dec 16, 2000 at 02:45:43PM -0500 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Louis A. Mamakos [001216 11:45] wrote: > > In article you write: > > > > > >On Sat, 16 Dec 2000, Alfred Perlstein wrote: > > > > > >> I think M_DONTWAIT is fine as it was, and M_TRYWAIT instead of M_TRY_WAIT. > > >> > > >> Leaving it as M_DONTWAIT should reduce the delta by quite a bit and > > >> M_TRYWAIT vs M_TRY_WAIT because you have M_DONTWAIT/M_DONTBLOCK. > > >> > > >> -Alfred > > > > > > I agree. Anyone else before I re-roll? :-) > > > > I second Alfred's suggestion. > > Is this just going to make portablity between the various *BSD kernels > more difficult for what's essentially a cosmetic change? I'm thinking > of things like KAME, ALTQ, etc. I agree, however this argument keeps coming up: "I thought M_WAIT meant it would wait forever!" Personally, I think developers should do a bit more research and should have noticed all the places where M_WAIT was followed by a check for NULL and be able to bridge the gap. So honestly, I'm against the change, but if it has to be done then I'd like to see the M_DONTWAIT and M_TRYWAIT. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Dec 16 12: 0:57 2000 From owner-freebsd-net@FreeBSD.ORG Sat Dec 16 12:00:55 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 3422A37B400 for ; Sat, 16 Dec 2000 12:00:55 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id eBGJutE75992; Sat, 16 Dec 2000 13:56:55 -0600 (CST) (envelope-from jlemon) Date: Sat, 16 Dec 2000 13:56:55 -0600 From: Jonathan Lemon To: "Louis A. Mamakos" Cc: Jonathan Lemon , bmilekic@technokratis.com, net@FreeBSD.ORG Subject: Re: Changing the names of some M_flags Message-ID: <20001216135655.L89463@prism.flugsvamp.com> References: <200012161934.eBGJYdj75335@prism.flugsvamp.com> <200012161945.eBGJjh507797@whizzo.transsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200012161945.eBGJjh507797@whizzo.transsys.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Dec 16, 2000 at 02:45:43PM -0500, Louis A. Mamakos wrote: > > In article you write: > > > > > >On Sat, 16 Dec 2000, Alfred Perlstein wrote: > > > > > >> I think M_DONTWAIT is fine as it was, and M_TRYWAIT instead of M_TRY_WAIT. > > >> > > >> Leaving it as M_DONTWAIT should reduce the delta by quite a bit and > > >> M_TRYWAIT vs M_TRY_WAIT because you have M_DONTWAIT/M_DONTBLOCK. > > >> > > >> -Alfred > > > > > > I agree. Anyone else before I re-roll? :-) > > > > I second Alfred's suggestion. > > Is this just going to make portablity between the various *BSD kernels > more difficult for what's essentially a cosmetic change? I'm thinking > of things like KAME, ALTQ, etc. Well, as it is a change in semantics, it does help to catch problems in porting. AFAIK, NetBSD (and probably Open) do not allow m_get() to return NULL in the M_WAIT case, so the underlying code will have to be changed in order to handle this difference anyway. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Dec 16 12: 3:14 2000 From owner-freebsd-net@FreeBSD.ORG Sat Dec 16 12:03:12 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id 79A6F37B400 for ; Sat, 16 Dec 2000 12:03:12 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G5O00MHWFPAYK@falla.videotron.net> for net@FreeBSD.ORG; Sat, 16 Dec 2000 15:03:10 -0500 (EST) Date: Sat, 16 Dec 2000 15:04:25 -0500 (EST) From: Bosko Milekic Subject: Re: Changing the names of some M_flags In-reply-to: <20001216115319.Z19572@fw.wintelcom.net> To: Alfred Perlstein Cc: "Louis A. Mamakos" , net@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 16 Dec 2000, Alfred Perlstein wrote: > > Is this just going to make portablity between the various *BSD kernels > > more difficult for what's essentially a cosmetic change? I'm thinking > > of things like KAME, ALTQ, etc. > > I agree, however this argument keeps coming up: > "I thought M_WAIT meant it would wait forever!" > > Personally, I think developers should do a bit more research > and should have noticed all the places where M_WAIT was followed > by a check for NULL and be able to bridge the gap. > > So honestly, I'm against the change, but if it has to be done > then I'd like to see the M_DONTWAIT and M_TRYWAIT. > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." This is _EXACTLY_ my opinion and standpoint on this issue. In terms of portability, though, let's be realistic: the name of a flag isn't going to be a major concern. When you port code, you typically have to read/understand what's going on anyway. So, if NetBSD for example, uses malloc() to allocate mbufs and passes the WAIT/NOWAIT flag directly down to malloc(), then it may as well never return if malloc() can't find a page. When porting to FreeBSD, the developer needs to know that that is not the case here and must make appropriate changes anyway. In fact, changing the flag may HELP the developer doing the porting into not making the mistake of assuming that it will be the same. Regards, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message