From linimon at FreeBSD.org Thu Oct 1 06:37:35 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Oct 1 06:37:42 2009 Subject: kern/139268: [if_bridge] [patch] allow if_bridge to forward just VLAN-tagged (or untagged) packets Message-ID: <200910010637.n916bZZo026560@freefall.freebsd.org> Old Synopsis: patch to allow if_bridge to forward just VLAN-tagged (or untagged) packets New Synopsis: [if_bridge] [patch] allow if_bridge to forward just VLAN-tagged (or untagged) packets Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Oct 1 06:36:57 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=139268 From Abbas_Zaidi at mentor.com Thu Oct 1 08:00:39 2009 From: Abbas_Zaidi at mentor.com (Zaidi, Abbas) Date: Thu Oct 1 08:01:02 2009 Subject: FreeBSD ipsec tunnel mode packet lost In-Reply-To: <20090930120822.GA73383@zeninc.net> Message-ID: Thanks Yvan for the help The problem got solved by changing the in security policy, on SGW, from ipsec level require to use, but I'm still not clear what the real issue was. Why we can't use require on it. Thanks, -----Original Message----- From: VANHULLEBUS Yvan [mailto:vanhu@FreeBSD.org] Sent: Wednesday, September 30, 2009 6:08 PM To: Zaidi, Abbas Cc: freebsd-net@freebsd.org; Ansari, Fakhir; Khan, Fayyaz Subject: Re: FreeBSD ipsec tunnel mode packet lost On Wed, Sep 30, 2009 at 01:16:47PM +0200, Zaidi, Abbas wrote: > Hi Hi. > I am having this strange problem establishing tunnel between FreeBSD and > linux, my network setup is [the setup] > Once the SAs get negotiated I send a ping request from FreeBSDe to > Linuxe. The packets get an ipsec header applied at FreeBSDr reaches > Linuxe a reply to packet comes back at Link1::e interface of FreeBSDr > and then packet gets lost. > > I am not using gif. Do I need it? Probably not. > I don't think any thing is wrong with ipsec as the seq of both in and > out sa are incrementing on every echo request reply. please check output of "netstat -s" (mainly sections esp, ipsec6, ip6), and see if some counters increase for each dropped packet. [...] > There is one strange thing about security policies as of linux in case > of tunnel there are 3 policies added (in, out, fwd) where as in FreeBSD > it only shows 2 (in, out). This is specific to Linux's IPsec stack implementation, just forget anything related to "fwd"..... Yvan. From vanhu at FreeBSD.org Thu Oct 1 08:11:33 2009 From: vanhu at FreeBSD.org (VANHULLEBUS Yvan) Date: Thu Oct 1 08:11:39 2009 Subject: FreeBSD ipsec tunnel mode packet lost In-Reply-To: References: <20090930120822.GA73383@zeninc.net> Message-ID: <20091001081131.GA76872@zeninc.net> On Thu, Oct 01, 2009 at 10:00:35AM +0200, Zaidi, Abbas wrote: > Thanks Yvan for the help > > The problem got solved by changing the in security policy, on SGW, from > ipsec level require to use, but I'm still not clear what the real issue > was. Why we can't use require on it. This sounds like you still have some configuration issues.... Are you sure your traffic is still encrypted ???? Yvan. From bynkaay at gmail.com Thu Oct 1 08:27:06 2009 From: bynkaay at gmail.com (www bynkaay com) Date: Thu Oct 1 08:27:12 2009 Subject: PROFESSIONAL CAR DIAGNOSTIC @www.bynkaay.com Message-ID: <20091001082948.C26C639B6E6@mx20.turkticaret.net> Newsletter NKAAY CO., HK LTD w w w . b y n k a a y . c o m Welcome to BYNKAAY Newsletter www.bynkaay.com Highly Quality Lowest Price 1 year warranty by NKAAY . since 1997 **** PROFESSIONAL CAR DIAGNOSTIC http://www.bynkaay.com/user_productlist.jsp?cmbcatlist=10&cmbsubcatlist=9&PAGENO=2 VAS 5054A Bluetooth - Original For purchase of Qty 4 or more, special price would be Euro 1050.00 per Pcs TWINB for BENZ and BMW (Benz C4 and Bmw GT1) For purchase of Qty 3 or more, special price would be Euro 758.00 per Set TOYOTA Denso DiagnosticTester II For purchase of Qty 4 or more, special price would be Euro 1573.00 per Set Renault Can Clip Diagnostic For purchase of Qty 4 or more, special price would be Euro 429.00 per Set PPS2000 Lexia-3 Citroen Peugeot Diagnostic For purchase of Qty 6 or more, special price would be Euro 215.00 per Set GM Tech2 Kit with CANdi Module For purchase of Qty 4 or more, special price would be Euro 1645.00 per Set Ford VCM IDS NEW For purchase of Qty 4 or more, special price would be Euro 475.00 per Set BMW OPS DIS SSS For purchase of Qty 3 or more, special price would be Euro 660.00 per Set NEW BMW GT1 DIS SSS For purchase of Qty 4 or more, special price would be Euro 475.00 per Set BMW INPA V502 For purchase of Qty 6 or more, special price would be Euro 200.00 per Set MB Star Diagnosis SET C3 (Jan.2009) For purchase of Qty 4 or more, special price would be Euro 374.00 per Set MB Star Diagnosis C4 For purchase of Qty 4 or more, special price would be Euro 458.00 per Set TOYOTA ITIS For purchase of Qty 3 or more, special price would be Euro 1187.00 per Set FLY100 Special Diagnostic tool for Honda For purchase of Qty 5 or more, special price would be Euro 400.00 per Set Porsche PIWIS For purchase of Qty 3 or more, special price would be Euro 1716.00 per Set Launch X431 (uptade by internet) For purchase of Qty 3 or more, special price would be Euro 1216.00 per Set Launch X431 (uptade by e-mail) For purchase of Qty 4 or more, special price would be Euro 930.00 per Set ALL OUR PRODCUTS http://www.bynkaay.com/productdivision.jsp BUY NOW! Shipping by DHL Please visit our web site www.bynkaay.com to see all products. -CONTACTS INSTANT: Mail : info@bynkaay.com MSN :bynkaay@hotmail.com YAHOO :bynkaay@yahoo.com Skype : bynkaay ICQ : 208344566 Support: info@nkaay.com Copyright (C) 2009 All Right Reserved NKAAY CO., HK LIMITED | http://www.nkaay.com Unsubscription : If you do not want to receive this newsletter please Click Here From pluknet at gmail.com Thu Oct 1 11:17:56 2009 From: pluknet at gmail.com (pluknet) Date: Thu Oct 1 11:18:02 2009 Subject: panic in soabort In-Reply-To: References: Message-ID: 2009/4/25 Robert Watson : > > On Fri, 24 Apr 2009, pluknet wrote: > >> 2009/4/23 Robert Watson : >>> >>> On Thu, 23 Apr 2009, pluknet wrote: >>> >>>> Please, give me comment on this. The panic is on 6.2-REL. Is it known to >>>> be fixed in the latter releases? >>> >>> It may well be -- there have been quite significant architectural >>> improvements to socket life cycle (etc) between 6.2 and 7.x releases, which >>> may well close the race causing this panic. ?However, we'll probably need to >>> learn a bit more in order to decide for sure. ?Could you convert the >>> trapping instruction pointer to file+offset in the source code? >> >> Looks I've lost the corresponding kernel.debug. Anyway I have such bt the >> first time. > > If you run into this again, let me know. ?Also, are you using accept filters > on the box? > Got it again (this time on 6.4-p5). Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault virtual address = 0x104 fault code = supervisor read, page not present instruction pointer = 0x20:0xc06a3425 stack pointer = 0x28:0xef764bb0 frame pointer = 0x28:0xef764bbc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 74303 (proftpd) db> bt 74303 Tracing pid 74303 tid 101039 td 0xcaa08820 _mtx_lock_sleep(ccd50768,caa08820,0,0,0) at _mtx_lock_sleep+0x9d soabort(ccd506f4) at soabort+0x82 soclose(d1aa8b20) at soclose+0x21a soo_close(c9f50a20,caa08820) at soo_close+0x63 fdrop_locked(c9f50a20,caa08820,caf78a00,ef764ca8,c06875f3,...) at fdrop_locked+0xd0 fdrop(c9f50a20,caa08820,caa08820,ef764c64,c0689055,...) at fdrop+0x41 closef(c9f50a20,caa08820,0,ef764d38,cad8f648,...) at closef+0x42f kern_close(caa08820,a,ef764d30,c08e1d4b,caa08820,...) at kern_close+0x20d close(caa08820,ef764d04) at close+0x10 syscall(bfbf003b,3b,bfbf003b,8150034,811a434,...) at syscall+0x2bf Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (6, FreeBSD ELF32, close), eip = 0x2832230f, esp = 0xbfbfe6bc, ebp = 0xbfbfe6d8 --- db> show proc 74303 Process 74303 (proftpd) at 0xcad8f648: state: NORMAL uid: 36830 gids: 36830 parent: pid 95478 at 0xc8e60000 ABI: FreeBSD ELF32 arguments: proftpd: fatich_1 - 93.118.217.18: IDLE threads: 1 101039 Run CPU 2 proftpd (gdb) list *(soabort+0x82) 0xc06ea2a6 is in soabort (/usr/src/sys/kern/uipc_socket.c:510). 505 int error; 506 507 error = (*so->so_proto->pr_usrreqs->pru_abort)(so); 508 if (error) { 509 ACCEPT_LOCK(); 510 SOCK_LOCK(so); 511 sotryfree(so); /* note: does not decrement the ref count */ 512 return error; 513 } 514 return (0); -- wbr, pluknet From pluknet at gmail.com Thu Oct 1 11:24:19 2009 From: pluknet at gmail.com (pluknet) Date: Thu Oct 1 11:24:26 2009 Subject: panic in soabort In-Reply-To: References: Message-ID: 2009/10/1 pluknet : > 2009/4/25 Robert Watson : >> >> On Fri, 24 Apr 2009, pluknet wrote: >> >>> 2009/4/23 Robert Watson : >>>> >>>> On Thu, 23 Apr 2009, pluknet wrote: >>>> >>>>> Please, give me comment on this. The panic is on 6.2-REL. Is it known to >>>>> be fixed in the latter releases? >>>> >>>> It may well be -- there have been quite significant architectural >>>> improvements to socket life cycle (etc) between 6.2 and 7.x releases, which >>>> may well close the race causing this panic. ?However, we'll probably need to >>>> learn a bit more in order to decide for sure. ?Could you convert the >>>> trapping instruction pointer to file+offset in the source code? >>> >>> Looks I've lost the corresponding kernel.debug. Anyway I have such bt the >>> first time. >> >> If you run into this again, let me know. ?Also, are you using accept filters >> on the box? >> > > Got it again (this time on 6.4-p5). P.S. It's funny to say: I got it on two boxes nearly simultaneously. Both from proftpd. See also my first mail (the same). > > Fatal trap 12: page fault while in kernel mode > cpuid = 2; apic id = 02 > fault virtual address ? = 0x104 > fault code ? ? ? ? ? ? ?= supervisor read, page not present > instruction pointer ? ? = 0x20:0xc06a3425 > stack pointer ? ? ? ? ? = 0x28:0xef764bb0 > frame pointer ? ? ? ? ? = 0x28:0xef764bbc > code segment ? ? ? ? ? ?= base 0x0, limit 0xfffff, type 0x1b > ? ? ? ? ? ? ? ? ? ? ? = DPL 0, pres 1, def32 1, gran 1 > processor eflags ? ? ? ?= resume, IOPL = 0 > current process ? ? ? ? = 74303 (proftpd) > > db> bt 74303 > Tracing pid 74303 tid 101039 td 0xcaa08820 > _mtx_lock_sleep(ccd50768,caa08820,0,0,0) at _mtx_lock_sleep+0x9d > soabort(ccd506f4) at soabort+0x82 > soclose(d1aa8b20) at soclose+0x21a > soo_close(c9f50a20,caa08820) at soo_close+0x63 > fdrop_locked(c9f50a20,caa08820,caf78a00,ef764ca8,c06875f3,...) at > fdrop_locked+0xd0 > fdrop(c9f50a20,caa08820,caa08820,ef764c64,c0689055,...) at fdrop+0x41 > closef(c9f50a20,caa08820,0,ef764d38,cad8f648,...) at closef+0x42f > kern_close(caa08820,a,ef764d30,c08e1d4b,caa08820,...) at kern_close+0x20d > close(caa08820,ef764d04) at close+0x10 > syscall(bfbf003b,3b,bfbf003b,8150034,811a434,...) at syscall+0x2bf > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (6, FreeBSD ELF32, close), eip = 0x2832230f, esp = > 0xbfbfe6bc, ebp = 0xbfbfe6d8 --- > db> show proc 74303 > Process 74303 (proftpd) at 0xcad8f648: > state: NORMAL > uid: 36830 ?gids: 36830 > parent: pid 95478 at 0xc8e60000 > ABI: FreeBSD ELF32 > arguments: proftpd: fatich_1 - 93.118.217.18: IDLE > threads: 1 > 101039 ? ? ? ? ? ? ? ? ? Run ? ? CPU 2 ? ? ? ? ? ? ? proftpd > > (gdb) list *(soabort+0x82) > 0xc06ea2a6 is in soabort (/usr/src/sys/kern/uipc_socket.c:510). > 505 ? ? ? ? ? ? int error; > 506 > 507 ? ? ? ? ? ? error = (*so->so_proto->pr_usrreqs->pru_abort)(so); > 508 ? ? ? ? ? ? if (error) { > 509 ? ? ? ? ? ? ? ? ? ? ACCEPT_LOCK(); > 510 ? ? ? ? ? ? ? ? ? ? SOCK_LOCK(so); > 511 ? ? ? ? ? ? ? ? ? ? sotryfree(so); ?/* note: does not decrement > the ref count */ > 512 ? ? ? ? ? ? ? ? ? ? return error; > 513 ? ? ? ? ? ? } > 514 ? ? ? ? ? ? return (0); > > -- > wbr, > pluknet > -- wbr, pluknet From universite at ukr.net Thu Oct 1 15:09:29 2009 From: universite at ukr.net (Vladislav V. Prodan) Date: Thu Oct 1 15:09:36 2009 Subject: Why not work whois -6 ? Message-ID: <4AC4C622.3060803@ukr.net> FreeBSD 8.0-BETA4 amd64 # whois -6 2a01:d0::1 whois: connect(): Connection refused In man whois written: -6 Use the IPv6 Resource Center (6bone) database. It contains net- work names and addresses for the IPv6 network. There are ideas on how to define membership of a particular block of ipv6? From rpaulo at freebsd.org Thu Oct 1 16:25:33 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Thu Oct 1 16:25:40 2009 Subject: Why not work whois -6 ? In-Reply-To: <4AC4C622.3060803@ukr.net> References: <4AC4C622.3060803@ukr.net> Message-ID: <33B977A4-00AD-48CA-A27C-89451DAF42AE@freebsd.org> On 1 Oct 2009, at 16:09, Vladislav V. Prodan wrote: > FreeBSD 8.0-BETA4 amd64 > > # whois -6 2a01:d0::1 > whois: connect(): Connection refused > > In man whois written: > -6 Use the IPv6 Resource Center (6bone) database. It > contains net- > work names and addresses for the IPv6 network. > > > There are ideas on how to define membership of a particular block of > ipv6? The 6bone whois server is dead AFAIK. Try whois -h whois.ripe.net 2a01:d0::1 -- Rui Paulo From remodeler at alentogroup.org Thu Oct 1 17:44:32 2009 From: remodeler at alentogroup.org (remodeler) Date: Thu Oct 1 17:44:38 2009 Subject: vimage-assigning interface to jail Message-ID: <20091001173851.M50386@alentogroup.org> I am experimenting with a vimage-enabled 8.0 kernel with multiple jails. I use the rc.d method to start jails, because of the warning in /etc/rc.d/jails about security. I would like to associate a vnet stack with each jail, and use netgraph to bridge the service jails to the physical interface. The ifconfig vnet additions allow an interface to be assigned to a particular jail; however, I do not know how to create a vimage separate from a jail as they are now unified (vimage -c creates both vnet and jail). I have also not had success passing the vnet parameter in rc.conf, which Julian mentioned might be as simple as "jail_xxx_extra_params". Is there a way to create a vimage w/o a jail and assign it to a jail w/ ifconfig vnet, or to pass the vnet parameter in rc.conf to the jails? I sincerely appreciate the work that's been done on vimage. I'm looking forward to netstat being updated to work with vimage. Thanks in advance. From universite at ukr.net Thu Oct 1 21:40:03 2009 From: universite at ukr.net (Vladislav V. Prodan) Date: Thu Oct 1 21:40:09 2009 Subject: kern/138666: [multicast] [panic] not working multicast through igmpproxy Message-ID: <200910012140.n91Le2C7091983@freefall.freebsd.org> The following reply was made to PR kern/138666; it has been noted by GNATS. From: "Vladislav V. Prodan" To: bug-followup@FreeBSD.org Cc: universite@ukr.net Subject: Re: kern/138666: [multicast] [panic] not working multicast through igmpproxy Date: Fri, 02 Oct 2009 00:31:39 +0300 Memtest86 + v2.01 said that with memory so good. P.S. Hynix 2Gb + Hynix 2Gb + Aeneon 1Gb + Aeneon 1Gb From dfilter at FreeBSD.ORG Fri Oct 2 01:40:03 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Fri Oct 2 01:40:10 2009 Subject: kern/139113: commit references a PR Message-ID: <200910020140.n921e2mw039579@freefall.freebsd.org> The following reply was made to PR kern/139113; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/139113: commit references a PR Date: Fri, 2 Oct 2009 01:35:09 +0000 (UTC) Author: qingli Date: Fri Oct 2 01:34:55 2009 New Revision: 197695 URL: http://svn.freebsd.org/changeset/base/197695 Log: Previously, if an address alias is configured on an interface, and this address alias has a prefix matching that of another address configured on the same interface, then the ARP entry for the alias is not deleted from the ARP table when that address alias is removed. This patch fixes the aforementioned issue. PR: kern/139113 MFC after: 3 days Modified: head/sys/netinet/in.c Modified: head/sys/netinet/in.c ============================================================================== --- head/sys/netinet/in.c Fri Oct 2 01:07:28 2009 (r197694) +++ head/sys/netinet/in.c Fri Oct 2 01:34:55 2009 (r197695) @@ -1060,6 +1060,8 @@ in_scrubprefix(struct in_ifaddr *target) !(target->ia_ifp->if_flags & IFF_LOOPBACK)) { error = ifa_del_loopback_route((struct ifaddr *)target, (struct sockaddr *)&target->ia_addr); + /* remove arp cache */ + arp_ifscrub(target->ia_ifp, IA_SIN(target)->sin_addr.s_addr); } if ((target->ia_flags & IFA_ROUTE) == 0) { @@ -1082,8 +1084,6 @@ in_scrubprefix(struct in_ifaddr *target) prefix = target->ia_addr.sin_addr; mask = target->ia_sockmask.sin_addr; prefix.s_addr &= mask.s_addr; - /* remove arp cache */ - arp_ifscrub(target->ia_ifp, IA_SIN(target)->sin_addr.s_addr); } IN_IFADDR_RLOCK(); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From yohanes at gmail.com Fri Oct 2 06:28:27 2009 From: yohanes at gmail.com (Yohanes Nugroho) Date: Fri Oct 2 06:28:34 2009 Subject: FreeBSD ARM network speed Message-ID: <260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa@mail.gmail.com> Hi All, I am continuing my work on CNX11XX/STR91XX (more info about the work: http://tinyhack.com/2009/09/28/cnx11xxstr91xx-freebsd-progress/), two important things left are the Flash/CFI driver, and network problem. The Flash/CFI in theory should be easy, but I will read more about it to make sure that I will not mess the boot loader part. And now about the network. The network speed is now around half of Linux on the same hardware. FTP-ing from the device to my computer (uploading 30 mb file), the speed is about 1.6-2 megabyte/second (the high speed is on the second time when the data is already cached). On Linux, I can upload the same file with the speed of about 3-4 megabyte/second. Some info about the device: RAM: 64 Mb, CPU FA526 (ARM4, no thumb instruction), Speed 200Mhz. MAC is part of SoC, PHY is ICPLUS IP101A I have two question: 1. Is the network speed in Freebsd ARM currently slower than Linux ARM? If it is slower, then how much slower is it? I can not find a comparison of network speed on Freebsd arm and Linux ARM. I am interested if anyone can provide me the comparison between Linux and Freebsd on NSLU2 or some other device. Just for information, changing some kernel options in the Linux version (such as the scheduler used) makes the network speed varies greatly (i think the variation is more than 30%, so in certain configuration it can be a slow as the current FreeBSD version). The network in Linux 2.4 kernel is faster than Linux 2.6. 2. What should I do to make the network faster (especially the sending from device part, to make it usable as a media server)? Here are the things that I have done: - using the scatter/gather feature of the hardware (this improves the speed a little bit) - using checksum offloading feature of the hardware (this improves the speed a little bit) - using task_queue for sending (this improves the speed a lot) - I have disabled spinlock debugging, and other debugging except for the DDB - I have used the -O2 optimization flag - I have checked that there is no error/retransmission (using wireshark), so all the packets are sent and received correctly - I have disabled IPV6 (here is my current configuration: http://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/str91xx/src/sys/arm/conf/CNS11XXNAS&REV=3) The specification for the STR9104 SoC is available on Cavium website for those who are interested, but it is not very clear, so in developing the network driver, I followed the logic used by the Linux driver (the initialization sequence, etc). The current code is at http://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/str91xx/src/sys/arm/econa/if_ece.c&REV=4 Here is how the sending part works on STR9104: - In the initialization part, I allocate a ring, the size of the ring is 256 entries (same as Linux version). - When being asked to send a packet, I will do the following thing: - stop the network TX DMA - put the address of each segment of the packet to the ring, and set a flag so that the entry in the ring will be sent by hardware - start the network TX DMA obviously there is a cleaning up part (freeing mbuf) that should be done. The network driver can generate interrupt when a packet has been sent (but can't tell which entry was sent). In the Linux version, this interrupt is not used, the clean up is done just after starting the TX DMA, at the send of the sending function, and I do the same in the FreeBSD driver . Usually only one entry that needs to be removed, so it is quite fast. Is there something obvious (or not so obvius) that I've missed? -- Regards Yohanes http://yohan.es/ From rpaulo at freebsd.org Fri Oct 2 08:38:15 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Fri Oct 2 08:38:27 2009 Subject: FreeBSD ARM network speed In-Reply-To: <260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa@mail.gmail.com> References: <260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa@mail.gmail.com> Message-ID: On 2 Oct 2009, at 06:58, Yohanes Nugroho wrote: > Hi All, > > I am continuing my work on CNX11XX/STR91XX (more info about the work: > http://tinyhack.com/2009/09/28/cnx11xxstr91xx-freebsd-progress/), two > important things left are the Flash/CFI driver, and network problem. > The Flash/CFI in theory should be easy, but I will read more about it > to make sure that I will not mess the boot loader part. And now about > the network. > > The network speed is now around half of Linux on the same hardware. > FTP-ing from the device to my computer (uploading 30 mb file), the > speed is about 1.6-2 megabyte/second (the high speed is on the second > time when the data is already cached). On Linux, I can upload the same > file with the speed of about 3-4 megabyte/second. > > Some info about the device: RAM: 64 Mb, CPU FA526 (ARM4, no thumb > instruction), Speed 200Mhz. MAC is part of SoC, PHY is ICPLUS IP101A > > I have two question: > 1. Is the network speed in Freebsd ARM currently slower than Linux > ARM? I see no problems on my ARM boards running FreeBSD. -- Rui Paulo From stas at FreeBSD.org Fri Oct 2 09:35:47 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Fri Oct 2 09:35:59 2009 Subject: FreeBSD ARM network speed In-Reply-To: <260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa@mail.gmail.com> References: <260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa@mail.gmail.com> Message-ID: <20091002133559.283d377f.stas@FreeBSD.org> On Fri, 2 Oct 2009 12:58:38 +0700 Yohanes Nugroho mentioned: > I have two question: > 1. Is the network speed in Freebsd ARM currently slower than Linux ARM? > I don't think so. Our network stack is arch-independent and should perform equally well on all platforms. I've been able to acchieve speeds up to 70 Mbps on my 180Mhz AT91 based board which uses very plain and dumb ethernet controller (although, DMA is supported). > Here is how the sending part works on STR9104: > > - In the initialization part, I allocate a ring, the size of the ring > is 256 entries (same as Linux version). > - When being asked to send a packet, I will do the following thing: > - stop the network TX DMA > - put the address of each segment of the packet to the ring, and set > a flag so that the entry in the ring will be sent by hardware > - start the network TX DMA > This looks weird. Why do you stop the TX engine to add more packets in the ring? This thing definitely can kill the network performace as the controller unable to transmit anything during the time you're filling the ring. You should not also generally transmit only one packet a time as in this case your driver will do a lot of extra work and, considering that you're stopping the TX engine when filling the ring, will prevent the adapter doing any useful work. The main strategy of the driver should be to keep the ring filled, waking up when some reasonable amount of space in the ring become available, and sleeping all other time when the adapter is working. I'm not sure why Linux doesn't use interrupt, but this looks really wrong. I'd suggest you to ananlyze the performance of network driver either by using the profiling tools available (kgmon, hardware counters (if any)) or/and via system monitoring tools (top, etc). Top, in particular, will allow you to see where all the CPU time went. -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20091002/e028db3a/attachment.pgp From stas at FreeBSD.org Fri Oct 2 11:30:12 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Fri Oct 2 11:30:19 2009 Subject: kern/127587: [bge] [request] if_bge(4) doesn't support BCM576X family Message-ID: <200910021130.n92BUCAa058052@freefall.freebsd.org> The following reply was made to PR kern/127587; it has been noted by GNATS. From: Stanislav Sedov To: Norikatsu Shigemura Cc: matthieu , bug-followup@FreeBSD.org Subject: Re: kern/127587: [bge] [request] if_bge(4) doesn't support BCM576X family Date: Fri, 2 Oct 2009 15:28:55 +0400 Hello, Norikatsu! Can you check, please, if the patch matthieu proposed works for you? Thanks! -- Stanislav Sedov ST4096-RIPE From yohanes at gmail.com Fri Oct 2 12:24:59 2009 From: yohanes at gmail.com (Yohanes Nugroho) Date: Fri Oct 2 12:25:11 2009 Subject: FreeBSD ARM network speed In-Reply-To: <20091002133559.283d377f.stas@FreeBSD.org> References: <260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa@mail.gmail.com> <20091002133559.283d377f.stas@FreeBSD.org> Message-ID: <260bb65e0910020524p374a7706r21c72a12b8ce93fb@mail.gmail.com> On Fri, Oct 2, 2009 at 4:35 PM, Stanislav Sedov wrote: > On Fri, 2 Oct 2009 12:58:38 +0700 > Yohanes Nugroho mentioned: > >> I have two question: >> 1. Is the network speed in Freebsd ARM currently slower than Linux ARM? >> > > I don't think so. ?Our network stack is arch-independent and should perform > equally well on all platforms. ?I've been able to acchieve speeds up to > 70 Mbps on my 180Mhz AT91 based board which uses very plain and dumb > ethernet controller (although, DMA is supported). Ok, glad to hear that :) because the first time I asked about a problem in the USB, it turns out that there was a problem in the latest source code in busdma, and I have spent several days thinking it was my bug. > > This looks weird. ?Why do you stop the TX engine to add more packets > in the ring? ?This thing definitely can kill the network performace yes, you are right, that is weird, I will have a look at it again. > The main strategy of the driver should be to keep the ring filled, > waking up when some reasonable amount of space in the ring become > available, and sleeping all other time when the adapter is working. Thank you for your enlightenment. > I'm not sure why Linux doesn't use interrupt, but this looks really > wrong. It is because the driver comes from a vendor (very messy code), not in the mainline kernel yet. the background story: - I have a cheap chinese NAS device (Agestar NCB3AST, cost about $50, now you can get it for about $40), comes with linux kernel 2.4, no source code was given. SoC used is Starsemi 9104 - I found out that there is a Linux source code for this SoC but for different device (with different hardware around the SoC). - Based on the source code, I ported it to work on Linux kernel 2.6, I didn't bother to try to clean up the source code - I am thinking of trying to add my code to mainline kernel, I realized that I didn't understand most of the source code - Bruce Simpson offered a device with same SoC (NSD-100) and I tried to port FreeBSD to it, thinking that I will understand the SoC better when rewriting the code - Starsemi was bought by cavium, the SoC is renamed to Econa CNS1102, and the datasheet was released. The datasheet is not very clear, so I am still basing some of my code on the Linux code (just the logic, not copy pasting, I understand about the license implication). > I'd suggest you to ananlyze the performance of network driver > either by using the profiling tools available (kgmon, hardware > counters (if any)) or/and via system monitoring tools (top, etc). > Top, in particular, will allow you to see where all the CPU time > went. I am testing in single user mode. Last time i tested using kgmon, it doesn't show any particular area that might cause the slowdown. Once again, thank you, I now have some ideas on what to do this weekend. -- Regards Yohanes http://yohan.es/ From is at rambler-co.ru Fri Oct 2 13:26:15 2009 From: is at rambler-co.ru (Igor Sysoev) Date: Fri Oct 2 13:26:26 2009 Subject: stuck TIME_WAIT sockets Message-ID: <20091002130646.GC89571@rambler-co.ru> The TIME_WAIT sockets suddenly started to grow on a host running FreeBSD 7.2-STABLE, date=2009.09.06.23.59.59 Usually there are 3,000-5,000 TIME_WAIT sockets on the host. However, today they stared to grow, have reached 110,000 sockets in hour and still remain on this level. net.inet.tcp.msl is 30000. The host uptime is 24 days, 21:53. I have saved a coredump and may try to help to debug the issue. -- Igor Sysoev http://sysoev.ru/en/ From is at rambler-co.ru Fri Oct 2 15:38:26 2009 From: is at rambler-co.ru (Igor Sysoev) Date: Fri Oct 2 15:38:33 2009 Subject: stuck TIME_WAIT sockets In-Reply-To: <20091002130646.GC89571@rambler-co.ru> References: <20091002130646.GC89571@rambler-co.ru> Message-ID: <20091002153824.GD89571@rambler-co.ru> On Fri, Oct 02, 2009 at 05:06:46PM +0400, Igor Sysoev wrote: > The TIME_WAIT sockets suddenly started to grow on a host running > FreeBSD 7.2-STABLE, date=2009.09.06.23.59.59 > Usually there are 3,000-5,000 TIME_WAIT sockets on the host. > However, today they stared to grow, have reached 110,000 sockets in hour > and still remain on this level. > net.inet.tcp.msl is 30000. > The host uptime is 24 days, 21:53. > > I have saved a coredump and may try to help to debug the issue. There are also 10 stuck LAST_ACK sockets. "swi4: clock sio" is usually idle, however, if I run netstat -an | grep TIME_WAIT | wc -l then swi4 gets some CPU: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 1 171 ki31 0K 16K CPU1 1 112.0H 98.29% idle: cpu1 12 root 1 171 ki31 0K 16K RUN 0 116.8H 94.78% idle: cpu0 14 root 1 -32 - 0K 16K WAIT 0 13:11 1.66% swi4: clock 26 root 1 -68 - 0K 16K WAIT 0 334:11 0.00% irq19: bge0 -- Igor Sysoev http://sysoev.ru/en/ From remodeler at alentogroup.org Fri Oct 2 18:24:30 2009 From: remodeler at alentogroup.org (remodeler) Date: Fri Oct 2 18:24:37 2009 Subject: vimage-assigning interface to jail In-Reply-To: <4AC4FD98.3000301@elischer.org> References: <20091001173851.M50386@alentogroup.org> <4AC4FD98.3000301@elischer.org> Message-ID: <20091002181509.M38849@alentogroup.org> Thank you to Julian for his kind response on my original question. I have succeeded with the "jail [...] vnet [...]" syntax Julian suggested. I looked through the /etc/rc.d/jail script and discovered why I cannot start a vnet jail with the rc mechanism - the vnet parameter to jail requires the -c flag, and the /etc/rc.d/jail script uses alternate syntax precluding the -c flag (instead of named parameters, it uses the four fixed parameters of path, hostname, ip, and command). I wonder if someone might help with a problem I am unable to resolve. I have no network connectivity from the vnet jail. I have opened the jail completely up for testing, mounting the host devfs, procfs, allowing raw sockets, and setting socket_unixiproute_only=0. I get the error message: PING 192.168.0.16 (192.168.0.16): 56 data bytes ping: sendto: No route to host and vimage testvnet route get default route: writing to routing socket: No such process I've read some of Julian's work on implementing FIB's (multiple kernel routing tables) - do I need to create and bind a route table (and socket) to the vnet? How do I do so? Also, I developed a local rc.d script that flexibly combines starting my vnet'd service jails and initiating the netgraph subsystem to bridge the virtual network stacks (jails) and physical ethernet interface using ng_ether, ng_eiface, and ng_bridge nodes. I intend to migrate the various security checks from /etc/rc.d/jail into my local script. That script uses a local configuration file with syntax similar to rc.conf for the jail values, but I don't see a clean way to load a netgraph configuration (and also notice there isn't a netgraph rc script, but examples for setting up local scripts). Is it a reasonable thought to parse a vizgraph dot file for netgraph configuration in my script? Thank you in advance. From is at rambler-co.ru Fri Oct 2 18:29:30 2009 From: is at rambler-co.ru (Igor Sysoev) Date: Fri Oct 2 18:29:37 2009 Subject: stuck TIME_WAIT sockets In-Reply-To: <20091002180621.GA1168@menantico.com> References: <20091002130646.GC89571@rambler-co.ru> <20091002180621.GA1168@menantico.com> Message-ID: <20091002182927.GA63007@rambler-co.ru> On Fri, Oct 02, 2009 at 02:06:21PM -0400, Skip Ford wrote: > Igor Sysoev wrote: > > The TIME_WAIT sockets suddenly started to grow on a host running > > FreeBSD 7.2-STABLE, date=2009.09.06.23.59.59 > > Usually there are 3,000-5,000 TIME_WAIT sockets on the host. > > However, today they stared to grow, have reached 110,000 sockets in hour > > and still remain on this level. > > net.inet.tcp.msl is 30000. > > The host uptime is 24 days, 21:53. > > Perhaps you need this patch? > > Author: peter > Date: Thu Aug 20 22:53:28 2009 > New Revision: 196410 > URL: http://svn.freebsd.org/changeset/base/196410 > > Log: > Fix signed comparison bug when ticks goes negative after 24 days of > uptime. This causes the tcp time_wait state code to fail to expire > sockets in timewait state. > > Approved by: re (kensmith) > > Modified: > head/sys/netinet/tcp_timewait.c Thank you. -- Igor Sysoev http://sysoev.ru/en/ From glen.j.barber at gmail.com Fri Oct 2 18:36:10 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Fri Oct 2 18:36:18 2009 Subject: vimage-assigning interface to jail In-Reply-To: <20091002181509.M38849@alentogroup.org> References: <20091001173851.M50386@alentogroup.org> <4AC4FD98.3000301@elischer.org> <20091002181509.M38849@alentogroup.org> Message-ID: <4ad871310910021136v3dc3cd2l520102bae715c2bc@mail.gmail.com> Hi On Fri, Oct 2, 2009 at 6:36 PM, remodeler wrote: [snip] > I wonder if someone might help with a problem I am unable to resolve. I have > no network connectivity from the vnet jail. I have opened the jail completely > up for testing, mounting the host devfs, procfs, allowing raw sockets, and > setting socket_unixiproute_only=0. I get the error message: > > ?PING 192.168.0.16 (192.168.0.16): 56 data bytes > ?ping: sendto: No route to host > Do you have your nameserver in /etc/resolv.conf ? -- Glen Barber From skip at menantico.com Fri Oct 2 19:02:52 2009 From: skip at menantico.com (Skip Ford) Date: Fri Oct 2 19:03:21 2009 Subject: stuck TIME_WAIT sockets In-Reply-To: <20091002130646.GC89571@rambler-co.ru> References: <20091002130646.GC89571@rambler-co.ru> Message-ID: <20091002180621.GA1168@menantico.com> Igor Sysoev wrote: > The TIME_WAIT sockets suddenly started to grow on a host running > FreeBSD 7.2-STABLE, date=2009.09.06.23.59.59 > Usually there are 3,000-5,000 TIME_WAIT sockets on the host. > However, today they stared to grow, have reached 110,000 sockets in hour > and still remain on this level. > net.inet.tcp.msl is 30000. > The host uptime is 24 days, 21:53. Perhaps you need this patch? Author: peter Date: Thu Aug 20 22:53:28 2009 New Revision: 196410 URL: http://svn.freebsd.org/changeset/base/196410 Log: Fix signed comparison bug when ticks goes negative after 24 days of uptime. This causes the tcp time_wait state code to fail to expire sockets in timewait state. Approved by: re (kensmith) Modified: head/sys/netinet/tcp_timewait.c Modified: head/sys/netinet/tcp_timewait.c --- head/sys/netinet/tcp_timewait.c Thu Aug 20 22:39:20 2009 (r196409) +++ head/sys/netinet/tcp_timewait.c Thu Aug 20 22:53:28 2009 (r196410) @@ -603,7 +603,7 @@ tcp_tw_2msl_scan(int reuse) INP_INFO_WLOCK_ASSERT(&V_tcbinfo); for (;;) { tw = TAILQ_FIRST(&V_twq_2msl); - if (tw == NULL || (!reuse && tw->tw_time > ticks)) + if (tw == NULL || (!reuse && (tw->tw_time - ticks) > 0)) break; INP_WLOCK(tw->tw_inpcb); tcp_twclose(tw, reuse); -- Skip From julian at elischer.org Fri Oct 2 19:14:33 2009 From: julian at elischer.org (Julian Elischer) Date: Fri Oct 2 19:14:40 2009 Subject: vimage-assigning interface to jail In-Reply-To: <20091002181509.M38849@alentogroup.org> References: <20091001173851.M50386@alentogroup.org> <4AC4FD98.3000301@elischer.org> <20091002181509.M38849@alentogroup.org> Message-ID: <4AC6511B.2050508@elischer.org> remodeler wrote: > Thank you to Julian for his kind response on my original question. I have > succeeded with the "jail [...] vnet [...]" syntax Julian suggested. I looked > through the /etc/rc.d/jail script and discovered why I cannot start a vnet > jail with the rc mechanism - the vnet parameter to jail requires the -c flag, > and the /etc/rc.d/jail script uses alternate syntax precluding the -c flag > (instead of named parameters, it uses the four fixed parameters of path, > hostname, ip, and command). > > I wonder if someone might help with a problem I am unable to resolve. I have > no network connectivity from the vnet jail. I have opened the jail completely > up for testing, mounting the host devfs, procfs, allowing raw sockets, and > setting socket_unixiproute_only=0. I get the error message: > > PING 192.168.0.16 (192.168.0.16): 56 data bytes > ping: sendto: No route to host > you need to assign an interface to the jail, either a real one, or a dummy one which connects to the main/base jail, where the packets can be routed. The ifconfig command is used for this in both cases but differently. what do you see when you type 'ifconfig' and 'netstat -rn' ine the jail? > and > > vimage testvnet route get default > route: writing to routing socket: No such process > > I've read some of Julian's work on implementing FIB's (multiple kernel routing > tables) - do I need to create and bind a route table (and socket) to the vnet? > How do I do so? > no you do not. The FIBS are all in a single jail. each jail comes with its own completely separate set of FIBs. > Also, I developed a local rc.d script that flexibly combines starting my > vnet'd service jails and initiating the netgraph subsystem to bridge the > virtual network stacks (jails) and physical ethernet interface using ng_ether, > ng_eiface, and ng_bridge nodes. I intend to migrate the various security > checks from /etc/rc.d/jail into my local script. That script uses a local > configuration file with syntax similar to rc.conf for the jail values, but I > don't see a clean way to load a netgraph configuration (and also notice there > isn't a netgraph rc script, but examples for setting up local scripts). Is it > a reasonable thought to parse a vizgraph dot file for netgraph configuration > in my script? not sure what that last one means :-) there is no netgraph rc feature, because netgraph is expected to be controlled by other facilities as an underlying method.. sorry I can't help more... time constraints.. > > Thank you in advance. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From skip at menantico.com Fri Oct 2 19:16:30 2009 From: skip at menantico.com (Skip Ford) Date: Fri Oct 2 19:16:36 2009 Subject: stuck TIME_WAIT sockets In-Reply-To: <20091002182927.GA63007@rambler-co.ru> References: <20091002130646.GC89571@rambler-co.ru> <20091002180621.GA1168@menantico.com> <20091002182927.GA63007@rambler-co.ru> Message-ID: <20091002192041.GB1168@menantico.com> Igor Sysoev wrote: > On Fri, Oct 02, 2009 at 02:06:21PM -0400, Skip Ford wrote: > > Igor Sysoev wrote: > > > The TIME_WAIT sockets suddenly started to grow on a host running > > > FreeBSD 7.2-STABLE, date=2009.09.06.23.59.59 > > > Usually there are 3,000-5,000 TIME_WAIT sockets on the host. > > > However, today they stared to grow, have reached 110,000 sockets in hour > > > and still remain on this level. > > > net.inet.tcp.msl is 30000. > > > The host uptime is 24 days, 21:53. > > > > Perhaps you need this patch? > > > > Author: peter > > Date: Thu Aug 20 22:53:28 2009 > > New Revision: 196410 > > URL: http://svn.freebsd.org/changeset/base/196410 > > > > Log: > > Fix signed comparison bug when ticks goes negative after 24 days of > > uptime. This causes the tcp time_wait state code to fail to expire > > sockets in timewait state. > > > > Approved by: re (kensmith) > > > > Modified: > > head/sys/netinet/tcp_timewait.c > > Thank you. You're welcome. There've been quite a few ticks-related commits lately, so you might need some of those before this one. Also, there's no 'MFC after' with this commit, which would worry me a little if I were you applying it to 7.2. Seems like a simple fix for a problem you appear to be hitting, however. -- Skip From remodeler at alentogroup.org Fri Oct 2 19:38:04 2009 From: remodeler at alentogroup.org (remodeler) Date: Fri Oct 2 19:38:11 2009 Subject: Fw: Re: vimage-assigning interface to jail In-Reply-To: <20091002190821.M69919@alentogroup.org> References: <20091001173851.M50386@alentogroup.org> <4AC4FD98.3000301@elischer.org> <20091002181509.M38849@alentogroup.org> <4ad871310910021136v3dc3cd2l520102bae715c2bc@mail.gmail.com> <20091002190821.M69919@alentogroup.org> Message-ID: <20091002195008.M13604@alentogroup.org> Thank you Glen: (sorry this copied twice to glen) > Do you have your nameserver in /etc/resolv.conf ? The jail and hostname both have /etc/resolv.conf set to a nameserver on the local host. I get the same error message pinging to the private-space address of the physical ethernet interface (the server is on a NAT'd development network): PING 192.168.0.10 (192.168.0.10): 56 data bytes ping: sendto: No route to host Some other information: #ngctl list There are 5 total nodes: Name: bridge0 Type: bridge ID: 00000007 Num hooks: 3 Name: ipfw Type: ipfw ID: 00000001 Num hooks: 0 Name: ngeth0 Type: eiface ID: 00000004 Num hooks: 1 Name: ngctl1495 Type: socket ID: 0000000f Num hooks: 0 Name: msk0 Type: ether ID: 00000002 Num hooks: 2 Firewall rules are permissive, allow any to any. The jail environment is: #ifconfig lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 nd6 options=33 maclabel mls/equal(equal-equal) eth0: flags=8843 metric 0 mtu 1500 ether 40:0a:0b:0c:0d:01 inet 172.26.75.10 netmask 0xffffffff broadcast 172.26.75.10 inet6 fe80::420a:bff:fe0c:d01%eth0 prefixlen 64 scopeid 0x2 nd6 options=33 maclabel mls/low(low-low) with eth0 being a ng_eiface node, moved to the jail with vimage -i testvnet ngeth0. The host environment is: #ifconfig msk0: flags=8843 metric 0 mtu 1500 options=11a ether [edited] inet 192.168.0.10 netmask 0xffffff00 broadcast 192.168.0.255 inet6 fe80::223:54ff:fe08:2bf7%msk0 prefixlen 64 scopeid 0x1 nd6 options=41 maclabel mls/low(low-low) media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 nd6 options=33 maclabel mls/equal(equal-equal) Output of jls from the host is: #jls # JID IP Address Hostname Path # 1 - testnet.myorg.org /jail/j/testnet I cannot set the IP address when I create the jail without an error: ip4.addr=${addr} gives "jail: vnet jails cannot have IP address restrictions"; ip4${addr} gives "jail: ip4: unknown jailsys value "172.26.72.10""; and ip=${addr} gives "jail: unknown parameter: ip". netstat -rn gives: #netstat: kvm not available: /dev/mem: Permission denied #Routing tables #rt_tables: symbol not in namelist /dev/mem is available in the jail environment, and /dev is mounted in the jail. I get a permission denied error on both /dev/mem and /dev/kmem: #ll /dev/kmem (or ll /dev/mem) #ls: /dev/kmem: Permission denied also, #vimage -l testvnet I do have vimage-enabled kernels on both the host and the jails (8.0). I originally installed a non-vimage kernel in the jails, and then updated to a vimage-enabled kernel following instructions in the handbook (using a template system). I am fairly certain I have the new kernel, as uname shows my new build date. Thank you very much again. ------- End of Forwarded Message ------- __ __ ________ ____ ___ ____ ____/ /__ / /__ _____ / ___/ _ \/ __ `__ \/ __ \/ __ / _ \/ / _ \/ ___/ / / / __/ / / / / / /_/ / /_/ / __/ / __/ / /_/ \___/_/ /_/ /_/\____/\__,_/\___/_/\___/_/ The information contained in this message is confidential and is intended for the addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. From julian at elischer.org Fri Oct 2 20:02:23 2009 From: julian at elischer.org (Julian Elischer) Date: Fri Oct 2 20:02:30 2009 Subject: Fw: Re: vimage-assigning interface to jail In-Reply-To: <20091002195008.M13604@alentogroup.org> References: <20091001173851.M50386@alentogroup.org> <4AC4FD98.3000301@elischer.org> <20091002181509.M38849@alentogroup.org> <4ad871310910021136v3dc3cd2l520102bae715c2bc@mail.gmail.com> <20091002190821.M69919@alentogroup.org> <20091002195008.M13604@alentogroup.org> Message-ID: <4AC65C51.7010506@elischer.org> remodeler wrote: > Thank you Glen: (sorry this copied twice to glen) > >> Do you have your nameserver in /etc/resolv.conf ? > > The jail and hostname both have /etc/resolv.conf set to a nameserver on the > local host. I get the same error message pinging to the private-space address > of the physical ethernet interface (the server is on a NAT'd development network): > > PING 192.168.0.10 (192.168.0.10): 56 data bytes > ping: sendto: No route to host > > Some other information: > > #ngctl list > There are 5 total nodes: > Name: bridge0 Type: bridge ID: 00000007 Num hooks: 3 > Name: ipfw Type: ipfw ID: 00000001 Num hooks: 0 > Name: ngeth0 Type: eiface ID: 00000004 Num hooks: 1 > Name: ngctl1495 Type: socket ID: 0000000f Num hooks: 0 > Name: msk0 Type: ether ID: 00000002 Num hooks: 2 > > Firewall rules are permissive, allow any to any. The jail environment is: > > #ifconfig > lo0: flags=8049 metric 0 mtu 16384 > options=3 > inet 127.0.0.1 netmask 0xff000000 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > nd6 options=33 > maclabel mls/equal(equal-equal) > eth0: flags=8843 metric 0 mtu 1500 > ether 40:0a:0b:0c:0d:01 > inet 172.26.75.10 netmask 0xffffffff broadcast 172.26.75.10 > inet6 fe80::420a:bff:fe0c:d01%eth0 prefixlen 64 scopeid 0x2 > nd6 options=33 > maclabel mls/low(low-low) > > with eth0 being a ng_eiface node, moved to the jail with vimage -i testvnet > ngeth0. The host environment is: > > #ifconfig > msk0: flags=8843 metric 0 mtu 1500 > options=11a > ether [edited] > inet 192.168.0.10 netmask 0xffffff00 broadcast 192.168.0.255 > inet6 fe80::223:54ff:fe08:2bf7%msk0 prefixlen 64 scopeid 0x1 > nd6 options=41 > maclabel mls/low(low-low) > media: Ethernet autoselect (100baseTX ) > status: active > lo0: flags=8049 metric 0 mtu 16384 > options=3 > inet 127.0.0.1 netmask 0xff000000 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > nd6 options=33 > maclabel mls/equal(equal-equal) > > Output of jls from the host is: > > #jls > # JID IP Address Hostname Path > # 1 - testnet.myorg.org /jail/j/testnet > > I cannot set the IP address when I create the jail without an error: > ip4.addr=${addr} gives "jail: vnet jails cannot have IP address restrictions"; > ip4${addr} gives "jail: ip4: unknown jailsys value "172.26.72.10""; and > ip=${addr} gives "jail: unknown parameter: ip". > > netstat -rn gives: > > #netstat: kvm not available: /dev/mem: Permission denied > #Routing tables > #rt_tables: symbol not in namelist > > /dev/mem is available in the jail environment, and /dev is mounted in the > jail. I get a permission denied error on both /dev/mem and /dev/kmem: > > #ll /dev/kmem (or ll /dev/mem) > #ls: /dev/kmem: Permission denied > > also, > > #vimage -l > testvnet > > I do have vimage-enabled kernels on both the host and the jails (8.0). I > originally installed a non-vimage kernel in the jails, and then updated to a > vimage-enabled kernel following instructions in the handbook (using a template > system). I am fairly certain I have the new kernel, as uname shows my new > build date. > I don't think the kernel in a jail matters. the following has a jail with a root of / for simplicity of testing: soekris# jail -c host.hostname=test path=/ vnet command=/bin/tcsh test# lo0: flags=8008 metric 0 mtu 16384 options=3 ---- back on host system: soekris# jls JID IP Address Hostname Path 1 - test / soekris# ifconfig vr2 vnet 1 soekris# ---- back on jail 'test' (1): test# ifconfig lo0: flags=8008 metric 0 mtu 16384 options=3 vr2: flags=8802 metric 0 mtu 1500 options=280b ether 00:00:24:c9:24:6a media: Ethernet autoselect (none) status: no carrier test# ifconfig vr2 172.28.15.1/24 test# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 172.28.15.0/24 link#2 U 0 0 vr2 172.28.15.1 link#2 UHS 0 0 lo0 test# route add default 172.28.15.2 add net default: gateway 172.28.15.2 test# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 172.28.15.2 UGS 0 0 vr2 172.28.15.0/24 link#2 U 0 0 vr2 172.28.15.1 link#2 UHS 0 0 lo0 test# I think you need to add a default rule for starters as there is no route to 192.168.x.x in your jail. Remember the jail can not see your base system. > Thank you very much again. > ------- End of Forwarded Message ------- > > > __ __ > ________ ____ ___ ____ ____/ /__ / /__ _____ > / ___/ _ \/ __ `__ \/ __ \/ __ / _ \/ / _ \/ ___/ > / / / __/ / / / / / /_/ / /_/ / __/ / __/ / > /_/ \___/_/ /_/ /_/\____/\__,_/\___/_/\___/_/ > > The information contained in this message is confidential and is intended > for the addressee only. Any unauthorized use, dissemination of the > information, or copying of this message is prohibited. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From pyunyh at gmail.com Fri Oct 2 20:14:47 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Oct 2 20:14:54 2009 Subject: FreeBSD ARM network speed In-Reply-To: <260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa@mail.gmail.com> References: <260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa@mail.gmail.com> Message-ID: <20091002201400.GJ1512@michelle.cdnetworks.com> On Fri, Oct 02, 2009 at 12:58:38PM +0700, Yohanes Nugroho wrote: > Hi All, > Hi, [...] > The specification for the STR9104 SoC is available on Cavium website > for those who are interested, but it is not very clear, so in > developing the network driver, I followed the logic used by the Linux > driver (the initialization sequence, etc). The current code is at > http://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/str91xx/src/sys/arm/econa/if_ece.c&REV=4 > > Here is how the sending part works on STR9104: > > - In the initialization part, I allocate a ring, the size of the ring > is 256 entries (same as Linux version). If ethernet controller does not support 1000baseT(I think it's fastethernt because ICPlus IP101A is 10/100 PHY) allocating 256 descriptors are waste of resource especially on 64MB systems, I think. > - When being asked to send a packet, I will do the following thing: > - stop the network TX DMA > - put the address of each segment of the packet to the ring, and set > a flag so that the entry in the ring will be sent by hardware > - start the network TX DMA > > obviously there is a cleaning up part (freeing mbuf) that should be > done. The network driver can generate interrupt when a packet has been > sent (but can't tell which entry was sent). In the Linux version, this > interrupt is not used, the clean up is done just after starting the TX > DMA, at the send of the sending function, and I do the same in the > FreeBSD driver . Usually only one entry that needs to be removed, so > it is quite fast. > > Is there something obvious (or not so obvius) that I've missed? > I briefly looked over the driver code and I can see missing bus_dmamap_sync(9) in several places as well as incorrect use of bus_dma(9). This may also affect performance because checking OWN bit wouldn't be correct in CPU's view without bus_dmamap_sync(9). Another poor performance might come from m_devget(9), I don't know whether controller really needs this type of copying(sorry, have no time to read data sheet) but m_devget(9) is really slow and time consuming operation because it has to copy entire frame to new mbuf. If you had to use m_devget(9) to align buffers on ETHER_ALIGN boundary I guess you can pass the alignment restriction to bus_dma(9). Of course, this requires the controller have ability to receive frames on even address boundary or no Rx buffer alignment limitation. I believe you should not stop DMA before sending another frame as you did in Rx handler. Basically you should make controller as busy as you can to get maximum performance and should reclaim transmitted buffers as soon as you noticed. Stopping DMA may take time since it may have to drain active DMA cycles. If the controller does not generate Tx completion interrupt after sending a frame, which is not likely, you may have to implement a kind of polling in separate thread or should use polling(9). Good luck! From remodeler at alentogroup.org Fri Oct 2 20:25:15 2009 From: remodeler at alentogroup.org (remodeler) Date: Fri Oct 2 20:25:22 2009 Subject: vimage-assigning interface to jail In-Reply-To: <4AC65C51.7010506@elischer.org> References: <20091001173851.M50386@alentogroup.org> <4AC4FD98.3000301@elischer.org> <20091002181509.M38849@alentogroup.org> <4ad871310910021136v3dc3cd2l520102bae715c2bc@mail.gmail.com> <20091002190821.M69919@alentogroup.org> <20091002195008.M13604@alentogroup.org> <4AC65C51.7010506@elischer.org> Message-ID: <20091002202650.M67240@alentogroup.org> Julian wrote: > I think you need to add a default rule for starters as there is no > route to 192.168.x.x in your jail. tempvnet# route show default route: writing to routing socket: No such process tempvnet# route add default 192.168.0.1 route: writing to routing socket: Network is unreachable add net default: gateway 192.168.0.1: Network is unreachable host#route show default route to: default ...snip output... I saw a reference to "accessing routing sockets in a FreeBSD jail is prohibited" in the wikipedia jail article. Thank you. From julian at elischer.org Fri Oct 2 21:10:53 2009 From: julian at elischer.org (Julian Elischer) Date: Fri Oct 2 21:11:01 2009 Subject: vimage-assigning interface to jail In-Reply-To: <20091002202650.M67240@alentogroup.org> References: <20091001173851.M50386@alentogroup.org> <4AC4FD98.3000301@elischer.org> <20091002181509.M38849@alentogroup.org> <4ad871310910021136v3dc3cd2l520102bae715c2bc@mail.gmail.com> <20091002190821.M69919@alentogroup.org> <20091002195008.M13604@alentogroup.org> <4AC65C51.7010506@elischer.org> <20091002202650.M67240@alentogroup.org> Message-ID: <4AC66C5F.4050000@elischer.org> remodeler wrote: > Julian wrote: > >> I think you need to add a default rule for starters as there is no >> route to 192.168.x.x in your jail. > > tempvnet# route show default > route: writing to routing socket: No such process > > tempvnet# route add default 192.168.0.1 > route: writing to routing socket: Network is unreachable > add net default: gateway 192.168.0.1: Network is unreachable > > host#route show default > route to: default > ...snip output... > > I saw a reference to "accessing routing sockets in a FreeBSD jail is > prohibited" in the wikipedia jail article. Without doing anything extra except booting, (with no jails started), what happens when you duplicate my commands in the previous email? > > Thank you. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From remodeler at alentogroup.org Fri Oct 2 22:37:33 2009 From: remodeler at alentogroup.org (remodeler) Date: Fri Oct 2 22:37:40 2009 Subject: vimage-assigning interface to jail In-Reply-To: <4AC66C5F.4050000@elischer.org> References: <20091001173851.M50386@alentogroup.org> <4AC4FD98.3000301@elischer.org> <20091002181509.M38849@alentogroup.org> <4ad871310910021136v3dc3cd2l520102bae715c2bc@mail.gmail.com> <20091002190821.M69919@alentogroup.org> <20091002195008.M13604@alentogroup.org> <4AC65C51.7010506@elischer.org> <20091002202650.M67240@alentogroup.org> <4AC66C5F.4050000@elischer.org> Message-ID: <20091002223304.M55101@alentogroup.org> Hi: > Without doing anything extra except booting, (with no jails started), > what happens when you duplicate my commands in the previous email? #jail -c host.hostname=test path=/ vnet persist I substituted persist parameter for command=/bin/tcsh in your example, otherwise the jail is destroyed when I exit the shell to enter the next command: #ifconfig msk0 vnet 1 test# ifconfig lo0: flags=8008 metric 0 mtu 16384 options=3 maclabel mls/equal(equal-equal) msk0: flags=8842 metric 0 mtu 1500 options=11a ether 00:23:54:08:2b:f7 maclabel mls/low(low-low) media: Ethernet autoselect test#ifconfig msk0 172.28.15.1/24 test#netstat -rn netstat: kvm not available: /dev/mem: Permission denied Routing tables rt_tables: symbol not in namelist test# route add default 192.168.0.1 route: writing to routing socket: Network is unreachable add net default: gateway 192.168.0.1: Network is unreachable #test# route add default 172.28.15.2 add net default: gateway 172.28.15.2 The host's IP address is set to 192.168.0.10, with a default route of 192.168.0.1 -- the route command succeeded when I used your example, although netstat -rn still fails with the same output as above. In my earlier correspondences, I was pushing a ng_eiface node to the jail instead of the physical ethernet device. Thank you. From oberman at es.net Fri Oct 2 23:18:27 2009 From: oberman at es.net (Kevin Oberman) Date: Fri Oct 2 23:18:34 2009 Subject: Unusual TCP options can cause FreeBSD to issue a reset Message-ID: <20091002231826.066291CC0E@ptavv.es.net> I have a system that is unable to connect to a FreeBSD system due to the odd formatting of the TCP options. The options contains only the timestamp which, if recommendations in RFC1323 are followed, are preceded by two NOP bytes to put the timestamp values on 4 byte boundaries. This system sends the 12 byte timestamp option alone, followed by two zero bytes to pad it. This meets the requirements of RFC793 and 1323 is explicit that stacks must accept this, even though it results in sub-optimal performance and does not meet the recommendations in 1323 appendix A. Any idea if this is hard to fix? I see in on both 7.2 and 8.0. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From julian at elischer.org Fri Oct 2 23:38:44 2009 From: julian at elischer.org (Julian Elischer) Date: Fri Oct 2 23:38:51 2009 Subject: vimage-assigning interface to jail In-Reply-To: <20091002223304.M55101@alentogroup.org> References: <20091001173851.M50386@alentogroup.org> <4AC4FD98.3000301@elischer.org> <20091002181509.M38849@alentogroup.org> <4ad871310910021136v3dc3cd2l520102bae715c2bc@mail.gmail.com> <20091002190821.M69919@alentogroup.org> <20091002195008.M13604@alentogroup.org> <4AC65C51.7010506@elischer.org> <20091002202650.M67240@alentogroup.org> <4AC66C5F.4050000@elischer.org> <20091002223304.M55101@alentogroup.org> Message-ID: <4AC68F06.8060305@elischer.org> remodeler wrote: > Hi: > >> Without doing anything extra except booting, (with no jails started), >> what happens when you duplicate my commands in the previous email? > > #jail -c host.hostname=test path=/ vnet persist > > I substituted persist parameter for command=/bin/tcsh in your example, > otherwise the jail is destroyed when I exit the shell to enter the next command: > > #ifconfig msk0 vnet 1 > > test# ifconfig > lo0: flags=8008 metric 0 mtu 16384 > options=3 > maclabel mls/equal(equal-equal) > msk0: flags=8842 metric 0 mtu 1500 > options=11a > ether 00:23:54:08:2b:f7 > maclabel mls/low(low-low) > media: Ethernet autoselect > > test#ifconfig msk0 172.28.15.1/24 > > test#netstat -rn > netstat: kvm not available: /dev/mem: Permission denied > Routing tables > rt_tables: symbol not in namelist in the jail do: ls -l /dev/*mem > > test# route add default 192.168.0.1 > route: writing to routing socket: Network is unreachable > add net default: gateway 192.168.0.1: Network is unreachable quite correct think of these as two separate machines. one is on 192.168.0.x and the other is on 172.... obviously the one on 172..... can not set a default route of 192.x.x.x as it can't reach that address. unlike non vnet jails, vnet jails have *completely* separate network stacks and can not communicate with each other except via the wire (or via an pretend wire) (see the epair driver). > > #test# route add default 172.28.15.2 > add net default: gateway 172.28.15.2 > > The host's IP address is set to 192.168.0.10, with a default route of > 192.168.0.1 -- the route command succeeded when I used your example, although > netstat -rn still fails with the same output as above. In my earlier > correspondences, I was pushing a ng_eiface node to the jail instead of the > physical ethernet device. looks like you need to allow it to access /dev/(k)mem somehow. > > Thank you. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From kayvey at gmail.com Sat Oct 3 01:11:44 2009 From: kayvey at gmail.com (Kayven Riese) Date: Sat Oct 3 01:11:51 2009 Subject: Invitation to connect on LinkedIn Message-ID: <1566437500.13979.1254530558646.JavaMail.app@ech3-cdn07.prod> LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Kayven Confirm that you know Kayven Riese https://www.linkedin.com/e/isd/775818287/3Vv1tKWZ/ Every day, millions of professionals like Kayven Riese use LinkedIn to connect with colleagues, find experts, and explore opportunities. ------ (c) 2009, LinkedIn Corporation From weongyo.jeong at gmail.com Sat Oct 3 02:13:55 2009 From: weongyo.jeong at gmail.com (Weongyo Jeong) Date: Sat Oct 3 02:14:01 2009 Subject: zyd & TEW-424UB In-Reply-To: <20090923101750.GC84230@obspm.fr> References: <20090923101750.GC84230@obspm.fr> Message-ID: <20091003021412.GJ1454@weongyo> On Wed, Sep 23, 2009 at 12:17:50PM +0200, Albert Shih wrote: > Hi all > > I'm using FreeBSD 7-stable on my laptop. The wifi card is not working with > FreeBSD. > > So I just buy a > > Trendnet TEW-424UB > > wifi usb adapter. I find this model in the > > man zyd > > but when I plug my adapter (after add if_zyd_load="YES" in my loader.conf > and reboot) it's not working. > > The adapter is not attach to some zyd drivers but usbgen1 > > Anyone have a idea why this f(*!@)(# adapter don't work ? or better some > solution ? FWIW, according to OpenBSD's recent commit message, TRENDnet TEW-424UB has multiple revisions and different chipsets as follows: rev A ZD1211 V2 SiS163U V2.1R SiS163U V3.xR RTL8187B regards, Weongyo Jeong From weongyo.jeong at gmail.com Sat Oct 3 02:18:03 2009 From: weongyo.jeong at gmail.com (Weongyo Jeong) Date: Sat Oct 3 02:18:09 2009 Subject: zyd & TEW-424UB In-Reply-To: <20090930203813.GA2322@obspm.fr> References: <20090923101750.GC84230@obspm.fr> <20090924180914.GA1417@weongyo> <20090925195112.GE37873@obspm.fr> <7E9D5842-B5BF-424D-AC27-FC2B9D043C96@FreeBSD.org> <20090926223125.GD1417@weongyo> <4ABF2030.8010302@obspm.fr> <20090928195110.GA1454@weongyo> <20090930203813.GA2322@obspm.fr> Message-ID: <20091003021822.GK1454@weongyo> On Wed, Sep 30, 2009 at 10:38:13PM +0200, Albert Shih wrote: > Le 28/09/2009 ? 12:51:10-0700, Weongyo Jeong a ?crit > > On Sun, Sep 27, 2009 at 10:20:00AM +0200, Albert Shih wrote: > > > Le 27/09/2009 00:31, Weongyo Jeong a ?crit : > > > >>> > > > >>> Controller /dev/usb6: > > > >>> addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), > > > >>> Intel(0x0000), rev 1.00 > > > >>> port 1 powered > > > >>> port 2 addr 2: high speed, power 500 mA, config 1, > > > >>> RTL8187B_WLAN_Adapter(0x8189), vendor 0x0bda(0x0bda), rev 2.00 > > > >>> port 3 powered > > > >>> port 4 powered > > > >>> port 5 powered > > > >>> port 6 powered > > > >> > > > >> Maybe this is a urtw device? > > > > > > > > Yes it looks one of urtw devices. Albert, could you please try with > > > > urtw(4)? > > > > > > > Can you confirme the urtw is only in 8- and not in 7-Stable ? I don't > > > find any if_urtw if my /boot/kernel/ > > > > urtw(4) is only in STABLE_8 and CURRENT not in STABLE_7 because it's not > > backported. > > You right it's urtw driver for this usb wifi device. > > > > At this time do you think I can upgrade to 8-current or 8-stable (if > > > it's exist) ? The last time I try to upgrade to 8-current my laptop > > > don't boot.... and this is my work'laptop ... > > > > I don't know your symptom why you couldn't boot but other developers can > > help you if you submit error messages. > > I just switch to 8.0-RC1 and now everything work fine. > > But for the urtw, it's not work fine :-( I'm loosing the signal many time. > and with my other usb device (if_rum) it's very stable. > > I don't known if I can help. Currently urtw(4) has a TX problem depending on H/W and a week signal controlling algorithm because it'd written without the datasheet. These are on TODO list. regards, Weongyo Jeong From dougb at FreeBSD.org Sat Oct 3 02:50:44 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sat Oct 3 02:50:50 2009 Subject: Why not work whois -6 ? In-Reply-To: <4AC4C622.3060803@ukr.net> References: <4AC4C622.3060803@ukr.net> Message-ID: <4AC6BC01.8030606@FreeBSD.org> Vladislav V. Prodan wrote: > FreeBSD 8.0-BETA4 amd64 > > # whois -6 2a01:d0::1 > whois: connect(): Connection refused > > In man whois written: > -6 Use the IPv6 Resource Center (6bone) database. It contains > net- > work names and addresses for the IPv6 network. > > > There are ideas on how to define membership of a particular block of ipv6? I just committed r197725 in HEAD to deal with this, thanks for the reminder. I will MFC the change as soon as it's possible to do so. Doug -- This .signature sanitized for your protection From ml at netfence.it Sat Oct 3 15:16:31 2009 From: ml at netfence.it (Andrea Venturoli) Date: Sat Oct 3 15:16:38 2009 Subject: CARP and LACP Message-ID: <4AC7681F.5010304@netfence.it> Hello. Fast question: are the two above compatible? Can I use CARP over a lagg interface? bye & Thanks av. From tom at tomjudge.com Sat Oct 3 16:07:45 2009 From: tom at tomjudge.com (Tom Judge) Date: Sat Oct 3 16:07:52 2009 Subject: CARP and LACP In-Reply-To: <4AC7681F.5010304@netfence.it> References: <4AC7681F.5010304@netfence.it> Message-ID: <4AC77212.1000703@tomjudge.com> Andrea Venturoli wrote: > Hello. > > Fast question: are the two above compatible? > > Can I use CARP over a lagg interface? Yes it should work just fine, we use it here with lagg+carp and lagg+vlan+carp. Tom > > bye & Thanks > av. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From rihad at mail.ru Sun Oct 4 13:47:26 2009 From: rihad at mail.ru (rihad) Date: Sun Oct 4 13:47:33 2009 Subject: dummynet dropping too many packets Message-ID: <4AC8A76B.3050502@mail.ru> Hi, we have around 500-600 mbit/s traffic flowing through a 7.1R Dell PowerEdge w/ 2 GigE bce cards. There are currently around 4 thousand ISP users online limited by dummynet pipes of various speeds. According to netstat -s output around 500-1000 packets are being dropped every second (this accounts for wasting around 7-12 mbit/s worth of traffic according to systat -ifstat): # while :; do netstat -z -s 2>/dev/null | fgrep -w "output packets dropped"; sleep 1; done 16824 output packets dropped due to no bufs, etc. 548 output packets dropped due to no bufs, etc. 842 output packets dropped due to no bufs, etc. 709 output packets dropped due to no bufs, etc. 652 output packets dropped due to no bufs, etc. ^C Pipes have been created like this: ipfw pipe 1024 config bw 1024kbit/s mask dst-ip 0xffffffff queue 350KBytes etc., and then assigned to users by application (ipfw tablearg). I've tried playing with the queue setting, from as little as 1 slot to as much as 4096KBytes - packets are still being dropped, more or less. Should I somehow calculate the proper queue value for the given pipe width? The manpage says 50 slots is typical for Ethernet devices (not mentioning whether it's 10, 100 or 1000 mbit/s), and that's it. sysctls: kern.ipc.nmbclusters=50000 net.inet.ip.dummynet.io_fast=1 Polling can't be enabled with bce. Any hints? Should I provide any further info? Thanks. From rizzo at iet.unipi.it Sun Oct 4 14:42:32 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Sun Oct 4 14:42:40 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AC8A76B.3050502@mail.ru> References: <4AC8A76B.3050502@mail.ru> Message-ID: <20091004144909.GA42503@onelab2.iet.unipi.it> On Sun, Oct 04, 2009 at 06:47:23PM +0500, rihad wrote: > Hi, we have around 500-600 mbit/s traffic flowing through a 7.1R Dell > PowerEdge w/ 2 GigE bce cards. There are currently around 4 thousand ISP > users online limited by dummynet pipes of various speeds. According to > netstat -s output around 500-1000 packets are being dropped every second > (this accounts for wasting around 7-12 mbit/s worth of traffic according > to systat -ifstat): what kind of packets are you seeing as dropped ? please give the output of 'netstat -s output | grep drop' At those speeds you might be hitting various limits with your config (e.g. 50k nmbclusters is probably way too small for 4k users -- means you have an average of 10-15 buffers per user; the queue size of 350kbytes = 2.6Mbits means 2.6 seconds of buffering, which is quite high besides the fact that in order to scale to 4k users you would need over 1GB of kernel memory just for the buffers). I'd most likely suspect the nmbclusters argument. netstat -m might give you some useful stats. cheers luigi > # while :; do netstat -z -s 2>/dev/null | fgrep -w "output packets > dropped"; sleep 1; done > 16824 output packets dropped due to no bufs, etc. > 548 output packets dropped due to no bufs, etc. > 842 output packets dropped due to no bufs, etc. > 709 output packets dropped due to no bufs, etc. > 652 output packets dropped due to no bufs, etc. > ^C > > Pipes have been created like this: > ipfw pipe 1024 config bw 1024kbit/s mask dst-ip 0xffffffff queue 350KBytes > etc., and then assigned to users by application (ipfw tablearg). > > I've tried playing with the queue setting, from as little as 1 slot to > as much as 4096KBytes - packets are still being dropped, more or less. > Should I somehow calculate the proper queue value for the given pipe > width? The manpage says 50 slots is typical for Ethernet devices (not > mentioning whether it's 10, 100 or 1000 mbit/s), and that's it. > > sysctls: > kern.ipc.nmbclusters=50000 > net.inet.ip.dummynet.io_fast=1 > > Polling can't be enabled with bce. > > Any hints? Should I provide any further info? > > Thanks. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From rihad at mail.ru Sun Oct 4 14:53:26 2009 From: rihad at mail.ru (rihad) Date: Sun Oct 4 14:53:38 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091004144909.GA42503@onelab2.iet.unipi.it> References: <4AC8A76B.3050502@mail.ru> <20091004144909.GA42503@onelab2.iet.unipi.it> Message-ID: <4AC8B6E3.2070101@mail.ru> Luigi Rizzo wrote: > On Sun, Oct 04, 2009 at 06:47:23PM +0500, rihad wrote: >> Hi, we have around 500-600 mbit/s traffic flowing through a 7.1R Dell >> PowerEdge w/ 2 GigE bce cards. There are currently around 4 thousand ISP >> users online limited by dummynet pipes of various speeds. According to >> netstat -s output around 500-1000 packets are being dropped every second >> (this accounts for wasting around 7-12 mbit/s worth of traffic according >> to systat -ifstat): > > what kind of packets are you seeing as dropped ? > please give the output of 'netstat -s output | grep drop' > The output packets, like I said: # netstat -s output | grep drop 2 connections closed (including 2 drops) 0 embryonic connections dropped 2 connections dropped by rexmit timeout 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 connections dropped by keepalive 0 dropped 2 dropped due to no socket 0 dropped due to full socket buffers 0 fragments dropped (dup or out of space) 2 fragments dropped after timeout 7538 output packets dropped due to no bufs, etc. The statistics are zeroed every 15 seconds in another window as I'm investigating the issue, but the rate is around 500-1000 lost packets every second at the current ~530 mbit/s load. > At those speeds you might be hitting various limits with your > config (e.g. 50k nmbclusters is probably way too small for I bet it isn't: 1967/5009/6976/50000 mbuf clusters in use (current/cache/total/max) > 4k users -- means you have an average of 10-15 buffers per user; > the queue size of 350kbytes = 2.6Mbits means 2.6 seconds of buffering, > which is quite high besides the fact that in order to scale to 4k users > you would need over 1GB of kernel memory just for the buffers). Aha. Can you be more specific about the kernel memory stuff? Which setting needs tweaking? I have another similar box with 2 em GigE interfaces working @220-230 mbit/s and virtually no out-of-bufs dropped packets as with bce @500-600 mbit. It too has 350KBytes dummynet queue sizes. And it too has adequate mbuf load: 3071/10427/13498/25600 mbuf clusters in use (current/cache/total/max) From rihad at mail.ru Sun Oct 4 14:56:00 2009 From: rihad at mail.ru (rihad) Date: Sun Oct 4 14:56:06 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091004144909.GA42503@onelab2.iet.unipi.it> References: <4AC8A76B.3050502@mail.ru> <20091004144909.GA42503@onelab2.iet.unipi.it> Message-ID: <4AC8B77D.6070703@mail.ru> Luigi Rizzo wrote: > On Sun, Oct 04, 2009 at 06:47:23PM +0500, rihad wrote: >> Hi, we have around 500-600 mbit/s traffic flowing through a 7.1R Dell >> PowerEdge w/ 2 GigE bce cards. There are currently around 4 thousand ISP >> users online limited by dummynet pipes of various speeds. According to >> netstat -s output around 500-1000 packets are being dropped every second >> (this accounts for wasting around 7-12 mbit/s worth of traffic according >> to systat -ifstat): > > At those speeds you might be hitting various limits with your > config (e.g. 50k nmbclusters is probably way too small for > 4k users -- means you have an average of 10-15 buffers per user; > the queue size of 350kbytes = 2.6Mbits means 2.6 seconds of buffering, > which is quite high besides the fact that in order to scale to 4k users > you would need over 1GB of kernel memory just for the buffers). top output: Mem: 2037M Active, 1248M Inact, 450M Wired, 184M Cache, 214M Buf, 17M Free I guess we're quite far from reaching 1GB of kernel memory. From rizzo at iet.unipi.it Sun Oct 4 15:04:40 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Sun Oct 4 15:04:46 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AC8B77D.6070703@mail.ru> References: <4AC8A76B.3050502@mail.ru> <20091004144909.GA42503@onelab2.iet.unipi.it> <4AC8B77D.6070703@mail.ru> Message-ID: <20091004151117.GA42877@onelab2.iet.unipi.it> On Sun, Oct 04, 2009 at 07:55:57PM +0500, rihad wrote: > Luigi Rizzo wrote: > >On Sun, Oct 04, 2009 at 06:47:23PM +0500, rihad wrote: > >>Hi, we have around 500-600 mbit/s traffic flowing through a 7.1R Dell > >>PowerEdge w/ 2 GigE bce cards. There are currently around 4 thousand ISP > >>users online limited by dummynet pipes of various speeds. According to > >>netstat -s output around 500-1000 packets are being dropped every second > >>(this accounts for wasting around 7-12 mbit/s worth of traffic according > >>to systat -ifstat): > > > >At those speeds you might be hitting various limits with your > >config (e.g. 50k nmbclusters is probably way too small for > >4k users -- means you have an average of 10-15 buffers per user; > >the queue size of 350kbytes = 2.6Mbits means 2.6 seconds of buffering, > >which is quite high besides the fact that in order to scale to 4k users > >you would need over 1GB of kernel memory just for the buffers). > > > top output: > Mem: 2037M Active, 1248M Inact, 450M Wired, 184M Cache, 214M Buf, 17M Free > > I guess we're quite far from reaching 1GB of kernel memory. of course, you'd have to configure also 500k nmbclusters (and then probably this would not fit) From rizzo at iet.unipi.it Sun Oct 4 15:08:40 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Sun Oct 4 15:08:47 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AC8B6E3.2070101@mail.ru> References: <4AC8A76B.3050502@mail.ru> <20091004144909.GA42503@onelab2.iet.unipi.it> <4AC8B6E3.2070101@mail.ru> Message-ID: <20091004151518.GB42877@onelab2.iet.unipi.it> On Sun, Oct 04, 2009 at 07:53:23PM +0500, rihad wrote: > Luigi Rizzo wrote: > >On Sun, Oct 04, 2009 at 06:47:23PM +0500, rihad wrote: > >>Hi, we have around 500-600 mbit/s traffic flowing through a 7.1R Dell > >>PowerEdge w/ 2 GigE bce cards. There are currently around 4 thousand ISP > >>users online limited by dummynet pipes of various speeds. According to > >>netstat -s output around 500-1000 packets are being dropped every second > >>(this accounts for wasting around 7-12 mbit/s worth of traffic according > >>to systat -ifstat): > > > >what kind of packets are you seeing as dropped ? > >please give the output of 'netstat -s output | grep drop' > > > The output packets, like I said: > # netstat -s output | grep drop > 2 connections closed (including 2 drops) > 0 embryonic connections dropped > 2 connections dropped by rexmit timeout > 0 connections dropped by persist timeout > 0 Connections (fin_wait_2) dropped because of timeout > 0 connections dropped by keepalive > 0 dropped > 2 dropped due to no socket > 0 dropped due to full socket buffers > 0 fragments dropped (dup or out of space) > 2 fragments dropped after timeout > 7538 output packets dropped due to no bufs, etc. > > The statistics are zeroed every 15 seconds in another window as I'm > investigating the issue, but the rate is around 500-1000 lost packets > every second at the current ~530 mbit/s load. > > >At those speeds you might be hitting various limits with your > >config (e.g. 50k nmbclusters is probably way too small for > > I bet it isn't: > 1967/5009/6976/50000 mbuf clusters in use (current/cache/total/max) > > >4k users -- means you have an average of 10-15 buffers per user; > >the queue size of 350kbytes = 2.6Mbits means 2.6 seconds of buffering, > >which is quite high besides the fact that in order to scale to 4k users > >you would need over 1GB of kernel memory just for the buffers). > Aha. Can you be more specific about the kernel memory stuff? Which > setting needs tweaking? > > > I have another similar box with 2 em GigE interfaces working @220-230 > mbit/s and virtually no out-of-bufs dropped packets as with bce @500-600 > mbit. It too has 350KBytes dummynet queue sizes. And it too has adequate > mbuf load: > 3071/10427/13498/25600 mbuf clusters in use (current/cache/total/max) I think a quick way to tell if the problem is in dummynet/ipfw or elsewhere would be to reconfigure the pipes (for short times, e.g. 1-2 minutes while you test things) as # first, try to remove the shaping to see if the drops # are still present or not ipfw pipe XX delete; ipfw pipe XX config // no buffering # second, do more traffic aggregation to see if the number of # pipes influences the drops. These are several different # configs to be tried. ipfw pipe XX delete; ipfw pipe XX config bw 500Mbits/s ipfw pipe XX delete; ipfw pipe XX config bw 50Mbits/s mask src-ip 0xffffff00 ipfw pipe XX delete; ipfw pipe XX config bw 5Mbits/s mask src-ip 0xfffffff0 and see if things change. If losses persist even removing dummynet, then of course it is a device problem. Also note that dummynet introduces some burstiness in the output, which might saturate the output queue in the card (no idea what is used by bce). This particular phenomenon could be reduced by raising HZ to 2000 or 4000. cheers luigi From rihad at mail.ru Sun Oct 4 15:29:03 2009 From: rihad at mail.ru (rihad) Date: Sun Oct 4 15:29:09 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091004151518.GB42877@onelab2.iet.unipi.it> References: <4AC8A76B.3050502@mail.ru> <20091004144909.GA42503@onelab2.iet.unipi.it> <4AC8B6E3.2070101@mail.ru> <20091004151518.GB42877@onelab2.iet.unipi.it> Message-ID: <4AC8BF3B.10601@mail.ru> Luigi Rizzo wrote: > On Sun, Oct 04, 2009 at 07:53:23PM +0500, rihad wrote: >> Luigi Rizzo wrote: >>> On Sun, Oct 04, 2009 at 06:47:23PM +0500, rihad wrote: >>>> Hi, we have around 500-600 mbit/s traffic flowing through a 7.1R Dell >>>> PowerEdge w/ 2 GigE bce cards. There are currently around 4 thousand ISP >>>> users online limited by dummynet pipes of various speeds. According to >>>> netstat -s output around 500-1000 packets are being dropped every second >>>> (this accounts for wasting around 7-12 mbit/s worth of traffic according >>>> to systat -ifstat): >>> what kind of packets are you seeing as dropped ? >>> please give the output of 'netstat -s output | grep drop' >>> >> The output packets, like I said: >> # netstat -s output | grep drop >> 2 connections closed (including 2 drops) >> 0 embryonic connections dropped >> 2 connections dropped by rexmit timeout >> 0 connections dropped by persist timeout >> 0 Connections (fin_wait_2) dropped because of timeout >> 0 connections dropped by keepalive >> 0 dropped >> 2 dropped due to no socket >> 0 dropped due to full socket buffers >> 0 fragments dropped (dup or out of space) >> 2 fragments dropped after timeout >> 7538 output packets dropped due to no bufs, etc. >> >> The statistics are zeroed every 15 seconds in another window as I'm >> investigating the issue, but the rate is around 500-1000 lost packets >> every second at the current ~530 mbit/s load. >> >>> At those speeds you might be hitting various limits with your >>> config (e.g. 50k nmbclusters is probably way too small for >> I bet it isn't: >> 1967/5009/6976/50000 mbuf clusters in use (current/cache/total/max) >> >>> 4k users -- means you have an average of 10-15 buffers per user; >>> the queue size of 350kbytes = 2.6Mbits means 2.6 seconds of buffering, >>> which is quite high besides the fact that in order to scale to 4k users >>> you would need over 1GB of kernel memory just for the buffers). >> Aha. Can you be more specific about the kernel memory stuff? Which >> setting needs tweaking? >> >> >> I have another similar box with 2 em GigE interfaces working @220-230 >> mbit/s and virtually no out-of-bufs dropped packets as with bce @500-600 >> mbit. It too has 350KBytes dummynet queue sizes. And it too has adequate >> mbuf load: >> 3071/10427/13498/25600 mbuf clusters in use (current/cache/total/max) > > I think a quick way to tell if the problem is in dummynet/ipfw or elsewhere > would be to reconfigure the pipes (for short times, e.g. 1-2 minutes > while you test things) as > > # first, try to remove the shaping to see if the drops > # are still present or not > ipfw pipe XX delete; ipfw pipe XX config // no buffering > > # second, do more traffic aggregation to see if the number of > # pipes influences the drops. These are several different > # configs to be tried. > ipfw pipe XX delete; ipfw pipe XX config bw 500Mbits/s > ipfw pipe XX delete; ipfw pipe XX config bw 50Mbits/s mask src-ip 0xffffff00 > ipfw pipe XX delete; ipfw pipe XX config bw 5Mbits/s mask src-ip 0xfffffff0 > > and see if things change. If losses persist even removing dummynet, > then of course it is a device problem. > Also note that dummynet introduces some burstiness in the output, > which might saturate the output queue in the card (no idea what is > used by bce). This particular phenomenon could be reduced by raising > HZ to 2000 or 4000. > Thanks for the tip. although I took an easier route by simply doing "ipfw add allow ip from any to any" before the pipe rules, and the buf drop rate instantly became 0. So the problem is dummynet/ipfw. Should I go to setting HZ to 2000? Mine is 1000. I somehow don't think the change would improve things. Maybe there's another way not involving a machine reboot? This is a production machine ;-( From gavin at FreeBSD.org Sun Oct 4 17:40:55 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Sun Oct 4 17:41:02 2009 Subject: bin/139346: [patch] arp(8) add option to remove static entries listed in file Message-ID: <200910041740.n94HetQ6060185@freefall.freebsd.org> Old Synopsis: [patch] add arp option to remove static entries listed in file New Synopsis: [patch] arp(8) add option to remove static entries listed in file Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Sun Oct 4 17:38:34 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). To submitter: Could you also please provide a patch to update the man page? Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=139346 From eugen at kuzbass.ru Mon Oct 5 03:23:26 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Mon Oct 5 03:23:33 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AC8A76B.3050502@mail.ru> References: <4AC8A76B.3050502@mail.ru> Message-ID: <20091005025521.GA52702@svzserv.kemerovo.su> On Sun, Oct 04, 2009 at 06:47:23PM +0500, rihad wrote: > sysctls: > kern.ipc.nmbclusters=50000 > net.inet.ip.dummynet.io_fast=1 I guess you should also try to increase pipes length: net.inet.ip.dummynet.hash_size=65536 net.inet.ip.dummynet.pipe_slot_limit=1000 And reconfigure pipes like this: ipfw pipe NNN config bw ... queue 1000 And default 'taildrop' policy of dummynet pipes may be guilty, you'd use GRED to prevent excessive drops. Eugene Grosbein From m.dyadchenko at sibset-team.ru Mon Oct 5 04:40:03 2009 From: m.dyadchenko at sibset-team.ru (Dyadchenko Mihail, Siberian Networks) Date: Mon Oct 5 04:40:09 2009 Subject: kern/134931: [route] [fib] Route messages sent to all socket listeners regardless of setfib Message-ID: <200910050440.n954e2Ja017950@freefall.freebsd.org> The following reply was made to PR kern/134931; it has been noted by GNATS. From: "Dyadchenko Mihail, Siberian Networks" To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/134931: [route] [fib] Route messages sent to all socket listeners regardless of setfib Date: Mon, 5 Oct 2009 11:30:32 +0700 Hello. Thanks, 7.2-Release was patched and recompiled successful, test with route add + route monitor also looks normal. May be on this week I will test in in real network. -- Dyadchenko Mihail Senior System Administrator, Siberian Networks Tel. (383) 205 0000 Fax. (383) 201-13-54 M.Dyadchenko@sibset-team.ru http://www.sibset.ru/ From rizzo at iet.unipi.it Mon Oct 5 06:03:47 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Mon Oct 5 06:03:55 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091005025521.GA52702@svzserv.kemerovo.su> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> Message-ID: <20091005061025.GB55845@onelab2.iet.unipi.it> On Mon, Oct 05, 2009 at 10:55:21AM +0800, Eugene Grosbein wrote: > On Sun, Oct 04, 2009 at 06:47:23PM +0500, rihad wrote: > > > sysctls: > > kern.ipc.nmbclusters=50000 > > net.inet.ip.dummynet.io_fast=1 > > I guess you should also try to increase pipes length: > > net.inet.ip.dummynet.hash_size=65536 > net.inet.ip.dummynet.pipe_slot_limit=1000 in fact, i forgot to ask, we'd need to know the output of "ipfw pipe show" just to get the idea if there is any known reason for the drop (e.g. queues too short, etc.) cheers luigi > And reconfigure pipes like this: > > ipfw pipe NNN config bw ... queue 1000 > > And default 'taildrop' policy of dummynet pipes may be guilty, > you'd use GRED to prevent excessive drops. > > Eugene Grosbein > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From andre at freebsd.org Mon Oct 5 08:51:11 2009 From: andre at freebsd.org (Andre Oppermann) Date: Mon Oct 5 08:51:17 2009 Subject: Unusual TCP options can cause FreeBSD to issue a reset In-Reply-To: <20091002231826.066291CC0E@ptavv.es.net> References: <20091002231826.066291CC0E@ptavv.es.net> Message-ID: <4AC9AD41.2070200@freebsd.org> Kevin Oberman wrote: > I have a system that is unable to connect to a FreeBSD system due to > the odd formatting of the TCP options. The options contains only the > timestamp which, if recommendations in RFC1323 are followed, are > preceded by two NOP bytes to put the timestamp values on 4 byte > boundaries. > > This system sends the 12 byte timestamp option alone, followed by two > zero bytes to pad it. This meets the requirements of RFC793 and 1323 is > explicit that stacks must accept this, even though it results in > sub-optimal performance and does not meet the recommendations in 1323 > appendix A. Just this alone should not cause a reset from FreeBSD. > Any idea if this is hard to fix? I see in on both 7.2 and 8.0. Can you post a detailed tcpdump of a failing connect? And please enable net.inet.tcp.log_debug which should give a better explanation on why FreeBSD thinks the connection is bad. -- Andre From rihad at mail.ru Mon Oct 5 08:53:23 2009 From: rihad at mail.ru (rihad) Date: Mon Oct 5 08:53:30 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091005061025.GB55845@onelab2.iet.unipi.it> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> Message-ID: <4AC9B400.9020400@mail.ru> Luigi Rizzo wrote: > On Mon, Oct 05, 2009 at 10:55:21AM +0800, Eugene Grosbein wrote: >> On Sun, Oct 04, 2009 at 06:47:23PM +0500, rihad wrote: >> >>> sysctls: >>> kern.ipc.nmbclusters=50000 >>> net.inet.ip.dummynet.io_fast=1 >> I guess you should also try to increase pipes length: >> >> net.inet.ip.dummynet.hash_size=65536 >> net.inet.ip.dummynet.pipe_slot_limit=1000 > > in fact, i forgot to ask, we'd need to know the output of > "ipfw pipe show" just to get the idea if there is any > known reason for the drop (e.g. queues too short, etc.) > The pipes are fine, each normally having 100-120 concurrent consumers (i.e. active users). (The max number of consumers allowed per pipe is hash_size*max_chain_len, normally 64*16==1024.) kern.ipc.nmbclusters=111111 And these are by default: #net.inet.ip.dummynet.hash_size=64 #net.inet.ip.dummynet.max_chain_len=16 Yesterday I set up a cronjob logging the number of drops in the past 15 minutes: */15 * * * * (echo -n "$(date) "; netstat -z -s 2>/dev/null | fgrep -w "output packets dropped") >> /tmp/bufs.log And here's bufs.log: Sun Oct 4 21:45:00 AZST 2009 418869 output packets dropped due to no bufs, etc. Sun Oct 4 22:00:00 AZST 2009 851693 output packets dropped due to no bufs, etc. Sun Oct 4 22:15:01 AZST 2009 932885 output packets dropped due to no bufs, etc. Sun Oct 4 22:30:00 AZST 2009 890522 output packets dropped due to no bufs, etc. Sun Oct 4 22:45:00 AZST 2009 1065931 output packets dropped due to no bufs, etc. Sun Oct 4 23:00:00 AZST 2009 937863 output packets dropped due to no bufs, etc. Sun Oct 4 23:15:01 AZST 2009 1018822 output packets dropped due to no bufs, etc. Sun Oct 4 23:30:00 AZST 2009 981922 output packets dropped due to no bufs, etc. Sun Oct 4 23:45:00 AZST 2009 1015124 output packets dropped due to no bufs, etc. Mon Oct 5 00:00:01 AZST 2009 1123926 output packets dropped due to no bufs, etc. Mon Oct 5 00:15:01 AZST 2009 948161 output packets dropped due to no bufs, etc. Mon Oct 5 00:30:00 AZST 2009 937277 output packets dropped due to no bufs, etc. Mon Oct 5 00:45:00 AZST 2009 875218 output packets dropped due to no bufs, etc. Mon Oct 5 01:00:00 AZST 2009 803527 output packets dropped due to no bufs, etc. Mon Oct 5 01:15:00 AZST 2009 728639 output packets dropped due to no bufs, etc. Mon Oct 5 01:30:00 AZST 2009 626154 output packets dropped due to no bufs, etc. Mon Oct 5 01:45:00 AZST 2009 519441 output packets dropped due to no bufs, etc. Mon Oct 5 02:00:00 AZST 2009 371098 output packets dropped due to no bufs, etc. Mon Oct 5 02:15:00 AZST 2009 681243 output packets dropped due to no bufs, etc. Mon Oct 5 02:30:00 AZST 2009 562909 output packets dropped due to no bufs, etc. Mon Oct 5 02:45:00 AZST 2009 426734 output packets dropped due to no bufs, etc. Mon Oct 5 03:00:00 AZST 2009 344619 output packets dropped due to no bufs, etc. Mon Oct 5 03:15:00 AZST 2009 90006 output packets dropped due to no bufs, etc. Mon Oct 5 03:30:00 AZST 2009 17064 output packets dropped due to no bufs, etc. Mon Oct 5 03:45:00 AZST 2009 3851 output packets dropped due to no bufs, etc. Mon Oct 5 04:00:00 AZST 2009 1323 output packets dropped due to no bufs, etc. Mon Oct 5 04:15:00 AZST 2009 0 output packets dropped due to no bufs, etc. Mon Oct 5 04:30:00 AZST 2009 0 output packets dropped due to no bufs, etc. Mon Oct 5 04:45:00 AZST 2009 0 output packets dropped due to no bufs, etc. Mon Oct 5 05:00:00 AZST 2009 0 output packets dropped due to no bufs, etc. Mon Oct 5 05:15:00 AZST 2009 0 output packets dropped due to no bufs, etc. Mon Oct 5 05:30:01 AZST 2009 0 output packets dropped due to no bufs, etc. Mon Oct 5 05:45:01 AZST 2009 0 output packets dropped due to no bufs, etc. Mon Oct 5 06:00:00 AZST 2009 0 output packets dropped due to no bufs, etc. Mon Oct 5 06:15:01 AZST 2009 0 output packets dropped due to no bufs, etc. Mon Oct 5 06:30:00 AZST 2009 0 output packets dropped due to no bufs, etc. Mon Oct 5 06:45:00 AZST 2009 0 output packets dropped due to no bufs, etc. Mon Oct 5 07:00:00 AZST 2009 0 output packets dropped due to no bufs, etc. Mon Oct 5 07:15:00 AZST 2009 0 output packets dropped due to no bufs, etc. Mon Oct 5 07:30:00 AZST 2009 0 output packets dropped due to no bufs, etc. Mon Oct 5 07:45:00 AZST 2009 0 output packets dropped due to no bufs, etc. Mon Oct 5 08:00:00 AZST 2009 0 output packets dropped due to no bufs, etc. Mon Oct 5 08:15:00 AZST 2009 0 output packets dropped due to no bufs, etc. Mon Oct 5 08:30:00 AZST 2009 0 output packets dropped due to no bufs, etc. Mon Oct 5 08:45:00 AZST 2009 0 output packets dropped due to no bufs, etc. Mon Oct 5 09:00:00 AZST 2009 0 output packets dropped due to no bufs, etc. Mon Oct 5 09:15:00 AZST 2009 0 output packets dropped due to no bufs, etc. Mon Oct 5 09:30:00 AZST 2009 0 output packets dropped due to no bufs, etc. Mon Oct 5 09:45:00 AZST 2009 0 output packets dropped due to no bufs, etc. Mon Oct 5 10:00:00 AZST 2009 0 output packets dropped due to no bufs, etc. Mon Oct 5 10:15:00 AZST 2009 0 output packets dropped due to no bufs, etc. Mon Oct 5 10:30:00 AZST 2009 177 output packets dropped due to no bufs, etc. Mon Oct 5 10:45:00 AZST 2009 1701 output packets dropped due to no bufs, etc. Mon Oct 5 11:00:01 AZST 2009 19933 output packets dropped due to no bufs, etc. Mon Oct 5 11:15:00 AZST 2009 30003 output packets dropped due to no bufs, etc. Mon Oct 5 11:30:00 AZST 2009 56712 output packets dropped due to no bufs, etc. Mon Oct 5 11:45:00 AZST 2009 78721 output packets dropped due to no bufs, etc. Mon Oct 5 12:00:01 AZST 2009 112518 output packets dropped due to no bufs, etc. Mon Oct 5 12:15:00 AZST 2009 7229 output packets dropped due to no bufs, etc. Mon Oct 5 12:30:01 AZST 2009 24965 output packets dropped due to no bufs, etc. Mon Oct 5 12:45:00 AZST 2009 75900 output packets dropped due to no bufs, etc. Mon Oct 5 13:00:00 AZST 2009 45002 output packets dropped due to no bufs, etc. Mon Oct 5 13:15:00 AZST 2009 67161 output packets dropped due to no bufs, etc. Mon Oct 5 13:30:00 AZST 2009 112591 output packets dropped due to no bufs, etc. As you can see the drops gradually went away completely at about 4:00 a.m., and started coming up at about 10:30 a.m., although at a lower rate, probably thanks to me bumping "ipfw ... queue NNN" up to 5000 at 10a.m. this morning. The traffic flow between 4a.m. and 10:30a.m., the "quiet" times, is about 200-330 mbit/s 5 minute average, without a single drop. But after that, in come the drops, no matter how high I set the queue. Should I try 10000 slots? 20000? I'm really sure there are plenty of heavy downloaders between 4a.m. and 10a.m., but still without a single drop before approx. 330 mbit/s! Strange, isn't it? This makes me believe I'm hitting some other global memory limit, rather than per-user limit, at around 340-350 mbit/s, causing drops. top and netstat -m are OK right now, though: Mem: 1870M Active, 1220M Inact, 481M Wired, 201M Cache, 214M Buf, 164M Free 15595/5385/20980/111112 mbuf clusters in use (current/cache/total/max) From eugen at kuzbass.ru Mon Oct 5 09:01:08 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Mon Oct 5 09:01:17 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AC9B400.9020400@mail.ru> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> Message-ID: <20091005090102.GA70430@svzserv.kemerovo.su> On Mon, Oct 05, 2009 at 01:53:20PM +0500, rihad wrote: > As you can see the drops gradually went away completely at about 4:00 > a.m., and started coming up at about 10:30 a.m., although at a lower > rate, probably thanks to me bumping "ipfw ... queue NNN" up to 5000 at > 10a.m. this morning. The traffic flow between 4a.m. and 10:30a.m., the > "quiet" times, is about 200-330 mbit/s 5 minute average, without a > single drop. But after that, in come the drops, no matter how high I set > the queue. Should I try 10000 slots? 20000? First switch from taildrop (default) to GRED, it is designed to fight your problem. Eugene Grosbein From rihad at mail.ru Mon Oct 5 09:29:04 2009 From: rihad at mail.ru (rihad) Date: Mon Oct 5 09:29:13 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091005090102.GA70430@svzserv.kemerovo.su> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> Message-ID: <4AC9BC5A.50902@mail.ru> Eugene Grosbein wrote: > On Mon, Oct 05, 2009 at 01:53:20PM +0500, rihad wrote: > >> As you can see the drops gradually went away completely at about 4:00 >> a.m., and started coming up at about 10:30 a.m., although at a lower >> rate, probably thanks to me bumping "ipfw ... queue NNN" up to 5000 at >> 10a.m. this morning. The traffic flow between 4a.m. and 10:30a.m., the >> "quiet" times, is about 200-330 mbit/s 5 minute average, without a >> single drop. But after that, in come the drops, no matter how high I set >> the queue. Should I try 10000 slots? 20000? > > First switch from taildrop (default) to GRED, it is designed to fight > your problem. > Oh, I almost forgot... Right now I've googled up and am reading this intro: http://www-rp.lip6.fr/~sf/WebSF/PapersWeb/iscc01.ps So turning to GRED would turn my FreeBSD router from dumb into a smart router that knows TCP? I thought pushing bits around at a lower level, and a sufficient queue size were enough. Still not sure why increasing queue size as high as I want doesn't completely eliminate drops. From rihad at mail.ru Mon Oct 5 09:48:32 2009 From: rihad at mail.ru (rihad) Date: Mon Oct 5 09:48:41 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091005090102.GA70430@svzserv.kemerovo.su> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> Message-ID: <4AC9C0ED.3020904@mail.ru> Eugene Grosbein wrote: > On Mon, Oct 05, 2009 at 01:53:20PM +0500, rihad wrote: > >> As you can see the drops gradually went away completely at about 4:00 >> a.m., and started coming up at about 10:30 a.m., although at a lower >> rate, probably thanks to me bumping "ipfw ... queue NNN" up to 5000 at >> 10a.m. this morning. The traffic flow between 4a.m. and 10:30a.m., the >> "quiet" times, is about 200-330 mbit/s 5 minute average, without a >> single drop. But after that, in come the drops, no matter how high I set >> the queue. Should I try 10000 slots? 20000? > > First switch from taildrop (default) to GRED, it is designed to fight > your problem. > red | gred w_q/min_th/max_th/max_p Make use of the RED (Random Early Detection) queue management algo- rithm. w_q and max_p are floating point numbers between 0 and 1 (0 not included), while min_th and max_th are integer numbers specify- ing thresholds for queue management (thresholds are computed in bytes if the queue has been defined in bytes, in slots otherwise). The dummynet(4) also supports the gentle RED variant (gred). Do you or someone else know what w_q and max_p are? There's just too much info for me to grasp here: http://www.icir.org/floyd/red.html From eugen at kuzbass.ru Mon Oct 5 09:56:02 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Mon Oct 5 09:56:09 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AC9BC5A.50902@mail.ru> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> Message-ID: <20091005095600.GA73335@svzserv.kemerovo.su> On Mon, Oct 05, 2009 at 02:28:58PM +0500, rihad wrote: > Oh, I almost forgot... Right now I've googled up and am reading this > intro: http://www-rp.lip6.fr/~sf/WebSF/PapersWeb/iscc01.ps > > So turning to GRED would turn my FreeBSD router from dumb into a smart > router that knows TCP? I thought pushing bits around at a lower level, > and a sufficient queue size were enough. No, it will still deal with IP packets but more clever. > Still not sure why increasing queue size as high as I want doesn't > completely eliminate drops. The goal is to make sources of traffic to slow down, this is the only way to descrease drops - any finite queue may be overhelmed with traffic. Taildrop does not really help with this. GRED does much better. Eugene Grosbein From rizzo at iet.unipi.it Mon Oct 5 09:58:07 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Mon Oct 5 09:58:14 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091005095600.GA73335@svzserv.kemerovo.su> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> Message-ID: <20091005100446.GA60244@onelab2.iet.unipi.it> On Mon, Oct 05, 2009 at 05:56:00PM +0800, Eugene Grosbein wrote: > On Mon, Oct 05, 2009 at 02:28:58PM +0500, rihad wrote: > > > Oh, I almost forgot... Right now I've googled up and am reading this > > intro: http://www-rp.lip6.fr/~sf/WebSF/PapersWeb/iscc01.ps > > > > So turning to GRED would turn my FreeBSD router from dumb into a smart > > router that knows TCP? I thought pushing bits around at a lower level, > > and a sufficient queue size were enough. > > No, it will still deal with IP packets but more clever. > > > Still not sure why increasing queue size as high as I want doesn't > > completely eliminate drops. > > The goal is to make sources of traffic to slow down, this is the only > way to descrease drops - any finite queue may be overhelmed with traffic. > Taildrop does not really help with this. GRED does much better. i think the first problem here is figure out _why_ we have the drops, as the original poster said that queues are configured with a very large amount of buffer (and i think there is a misconfiguration somewhere because the mbuf stats do not make sense) cheers luigi From eugen at kuzbass.ru Mon Oct 5 09:59:19 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Mon Oct 5 09:59:26 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AC9C0ED.3020904@mail.ru> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9C0ED.3020904@mail.ru> Message-ID: <20091005095916.GB73335@svzserv.kemerovo.su> On Mon, Oct 05, 2009 at 02:48:29PM +0500, rihad wrote: > >First switch from taildrop (default) to GRED, it is designed to fight > >your problem. > > red | gred w_q/min_th/max_th/max_p > Make use of the RED (Random Early Detection) queue > management algo- > rithm. w_q and max_p are floating point numbers between 0 > and 1 (0 > not included), while min_th and max_th are integer numbers > specify- > ing thresholds for queue management (thresholds are computed in > bytes if the queue has been defined in bytes, in slots > otherwise). > The dummynet(4) also supports the gentle RED variant (gred). > > Do you or someone else know what w_q and max_p are? > > There's just too much info for me to grasp here: > http://www.icir.org/floyd/red.html http://docs.freebsd.org/cgi/getmsg.cgi?fetch=126518+0+archive/2009/freebsd-net/20091004.freebsd-net Eugene Grosbein From eugen at kuzbass.ru Mon Oct 5 10:05:36 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Mon Oct 5 10:05:42 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091005100446.GA60244@onelab2.iet.unipi.it> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <20091005100446.GA60244@onelab2.iet.unipi.it> Message-ID: <20091005100532.GC73335@svzserv.kemerovo.su> On Mon, Oct 05, 2009 at 12:04:46PM +0200, Luigi Rizzo wrote: > > The goal is to make sources of traffic to slow down, this is the only > > way to descrease drops - any finite queue may be overhelmed with traffic. > > Taildrop does not really help with this. GRED does much better. > > i think the first problem here is figure out _why_ we have > the drops, as the original poster said that queues are configured > with a very large amount of buffer (and i think there is a > misconfiguration somewhere because the mbuf stats do not make > sense) That may be very simple, f.e. wide uplink channel and policy that dictates slower client speeds. Any taildrop queue would drop lots of packets. Eugene Grosbein From rihad at mail.ru Mon Oct 5 10:21:01 2009 From: rihad at mail.ru (rihad) Date: Mon Oct 5 10:21:08 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091005100532.GC73335@svzserv.kemerovo.su> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <20091005100446.GA60244@onelab2.iet.unipi.it> <20091005100532.GC73335@svzserv.kemerovo.su> Message-ID: <4AC9C88A.5050509@mail.ru> Eugene Grosbein wrote: > On Mon, Oct 05, 2009 at 12:04:46PM +0200, Luigi Rizzo wrote: > >>> The goal is to make sources of traffic to slow down, this is the only >>> way to descrease drops - any finite queue may be overhelmed with traffic. >>> Taildrop does not really help with this. GRED does much better. >> i think the first problem here is figure out _why_ we have >> the drops, as the original poster said that queues are configured >> with a very large amount of buffer (and i think there is a >> misconfiguration somewhere because the mbuf stats do not make >> sense) > > That may be very simple, f.e. wide uplink channel and policy that > dictates slower client speeds. Any taildrop queue would drop lots > of packets. > If uplink is e.g. 100 mbit/s, but data is fed to client by dummynet at 1 mbit/s, doesn't the _client's_ TCP software know to slow things down to not overwhelm 1 mbit/s? Where has TCP slow-start gone? My router box isn't some application proxy that starts downloading at full 100 mbit/s thus quickly filling client's 1 mbit/s link. It's just a router. Although it doesn't yet make sense to me, I'll try going to GRED soon. From rihad at mail.ru Mon Oct 5 10:52:41 2009 From: rihad at mail.ru (rihad) Date: Mon Oct 5 10:52:48 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091005095600.GA73335@svzserv.kemerovo.su> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> Message-ID: <4AC9CFF7.3090208@mail.ru> Eugene Grosbein wrote: > On Mon, Oct 05, 2009 at 02:28:58PM +0500, rihad wrote: > >> Still not sure why increasing queue size as high as I want doesn't >> completely eliminate drops. > > The goal is to make sources of traffic to slow down, this is the only > way to descrease drops - any finite queue may be overhelmed with traffic. > Taildrop does not really help with this. GRED does much better. > Alright, so I changed to gred by adding to each config command: ipfw ... gred 0.002/900/1000/0.1 queue 1000 and reconfigured. Still around 300-400 drops per second, which was typical at this load level before with taildrop anyway. There are around 3-5 mbit/s being wasted according to systat -ifstat. Should I now increase slots to 5-10-20k? Very strange. "ipfw pipe show" correctly shows that gred is at work. For example: 00512: 512.000 Kbit/s 0 ms 1000 sl. 79 queues (64 buckets) GRED w_q 0.001999 min_th 900 max_th 1000 max_p 0.099991 mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 ... From rizzo at iet.unipi.it Mon Oct 5 11:00:47 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Mon Oct 5 11:00:54 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AC9CFF7.3090208@mail.ru> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <4AC9CFF7.3090208@mail.ru> Message-ID: <20091005110726.GA62598@onelab2.iet.unipi.it> On Mon, Oct 05, 2009 at 03:52:39PM +0500, rihad wrote: > Eugene Grosbein wrote: > >On Mon, Oct 05, 2009 at 02:28:58PM +0500, rihad wrote: > > > >>Still not sure why increasing queue size as high as I want doesn't > >>completely eliminate drops. > > > >The goal is to make sources of traffic to slow down, this is the only > >way to descrease drops - any finite queue may be overhelmed with traffic. > >Taildrop does not really help with this. GRED does much better. > > > > Alright, so I changed to gred by adding to each config command: > ipfw ... gred 0.002/900/1000/0.1 queue 1000 > and reconfigured. Still around 300-400 drops per second, which was > typical at this load level before with taildrop anyway. There are around > 3-5 mbit/s being wasted according to systat -ifstat. > > Should I now increase slots to 5-10-20k? > Very strange. > > "ipfw pipe show" correctly shows that gred is at work. For example: > 00512: 512.000 Kbit/s 0 ms 1000 sl. 79 queues (64 buckets) > GRED w_q 0.001999 min_th 900 max_th 1000 max_p 0.099991 > mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 > ... you keep omitting the important info i.e. whether individual pipes have drops, significant queue lenghts and so on. i am giving up! From bugmaster at FreeBSD.org Mon Oct 5 11:06:57 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 5 11:09:02 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200910051106.n95B6uOW088747@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139162 net [fwip] [panic] 8.0-RC1 panics if using IP over firewir o kern/139145 net [ip6] IPv6 blackhole / reject routes broken o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139113 net [arp] removing IP alias doesn't delete permanent arp e o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138999 net [libc] lighttpd/php-cgi with freebsd sendfile(2) enabl o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o kern/138694 net [bge] FreeBSD 6.3 release does not recognize Broadcom o amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138676 net [route] after buildworld not work local routes [regres f kern/138666 net [multicast] [panic] not working multicast through igmp o kern/138660 net [igb] igb driver troubles in 8.0-BETA4 o kern/138652 net TCP window scaling value calculated incorrectly? o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138390 net [gif] [patch] NULL pointer dereference in gif_input() o kern/138378 net [altq] [patch] Memory leak in hfsc_class_modify() in f o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR on 8.0-BE o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/138130 net [netinet] [patch] Resource leak in LibAliasRefreshModu o kern/138046 net [tcp] tcp sockets stay in SYN_SENT even after receivin o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137795 net [sctp] [panic] mtx_lock() of destroyed mutex o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137317 net [tcp] logs full of syncache problems o kern/137292 net [ste] DFE-580TX not working properly o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137170 net [ath] atheros AR9285 not recognised o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136482 net [age] Attansic L1 Gigabit Ethernet recieves multicasts o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135836 net [bce] bce BCM5709 Watchdog after warm boot - ok after o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/135067 net [patch] [fib] Incorrect KASSERTs in sys/net/route.c o kern/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se o kern/134931 net [route] [fib] Route messages sent to all socket listen o kern/134658 net [bce] bce driver fails on PowerEdge m610 blade. o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134369 net [route] [ip6] IPV6 in Head broken for routing table up o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133786 net [netinet] [patch] ip_input might cause kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132625 net [iwn] iwn drivers don't support setting country o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] [patch] if_sis short cable fix problems with Net s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 357 problems total. From decvt100 at gmail.com Mon Oct 5 11:20:03 2009 From: decvt100 at gmail.com (Carlos) Date: Mon Oct 5 11:20:10 2009 Subject: kern/137776: [rum] panic in rum(4) driver on 8.0-BETA2 Message-ID: <200910051120.n95BK2di000889@freefall.freebsd.org> The following reply was made to PR kern/137776; it has been noted by GNATS. From: Carlos To: bug-followup@freebsd.org, flz@freebsd.org Cc: Subject: Re: kern/137776: [rum] panic in rum(4) driver on 8.0-BETA2 Date: Mon, 5 Oct 2009 12:52:32 +0200 hi list, I would like to say sorry for my poor english i want to say that I can reproduce this panic always. If i run wine + WoW (World of Warcraft), the internet connection is lost and then if i run /etc/rc.d/netif restart the panic always appear. if you need make tests i can make it on my pc and give you the results of the test. I am only a normal user, not a developer user. If I have to apply patch (maybe) I need some help in how to apply it. My system is running 8.0-RC1 FreeBSD 8.0-RC1 #0: Thu Sep 17 20:45:19 UTC 2009 r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 and this is my panic: kgdb /boot/kernel/kernel.symbols vmcore.1 GNU gdb 6.1.1 [FreeBSD] This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x20 fault code = supervisor read, page not present instruction pointer = 0x20:0xc09408a8 stack pointer = 0x28:0xe89809a4 frame pointer = 0x28:0xe89809c0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2321 (wpa_supplicant) trap number = 12 panic: page fault cpuid = 1 Uptime: 3m18s Physical memory: 2022 MB Dumping 222 MB: 207 191 175 159 143 127 111 95 79 63 47 31 15 Reading symbols from /boot/kernel/geom_journal.ko...Reading symbols from /boot/kernel/geom_journal.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_journal.ko Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /boot/kernel/coretemp.ko.symbols...done. done. Loaded symbols for /boot/kernel/coretemp.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from /boot/kernel/atapicam.ko.symbols...done. done. Loaded symbols for /boot/kernel/atapicam.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko Reading symbols from /usr/local/modules/rtc.ko...done. Loaded symbols for /usr/local/modules/rtc.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc08823c7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xc08826b9 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:579 #3 0xc0bb346c in trap_fatal (frame=0xe8980964, eva=32) at /usr/src/sys/i386/i386/trap.c:933 #4 0xc0bb36f0 in trap_pfault (frame=0xe8980964, usermode=0, eva=32) at /usr/src/sys/i386/i386/trap.c:846 #5 0xc0bb40d5 in trap (frame=0xe8980964) at /usr/src/sys/i386/i386/trap.c:528 #6 0xc0b96a4b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #7 0xc09408a8 in ieee80211_crypto_encap (ni=0xc6b5d000, m=0xc776dc00) at /usr/src/sys/net80211/ieee80211_crypto.c:560 #8 0xc07ca32b in rum_start (ifp=0xc67e2400) at /usr/src/sys/dev/usb/wlan/if_rum.c:1216 #9 0xc0923582 in if_start (ifp=0xc67e2400) at /usr/src/sys/net/if.c:3242 #10 0xc092750b in if_transmit (ifp=0xc67e2400, m=0xc6a60c00) at /usr/src/sys/net/if.c:3254 #11 0xc0963082 in ieee80211_start (ifp=0xc6409400) at /usr/src/sys/net80211/ieee80211_output.c:362 #12 0xc0923582 in if_start (ifp=0xc6409400) at /usr/src/sys/net/if.c:3242 #13 0xc092750b in if_transmit (ifp=0xc6409400, m=0xc6acc200) at /usr/src/sys/net/if.c:3254 #14 0xc092bd90 in ether_output_frame (ifp=0xc6409400, m=0xc6acc200) at /usr/src/sys/net/if_ethersubr.c:452 #15 0xc092c77b in ether_output (ifp=0xc6409400, m=0xc6acc200, dst=0xe8980b98, ro=0x0) at /usr/src/sys/net/if_ethersubr.c:423 #16 0xc09626fd in ieee80211_output (ifp=0xc6409400, m=0xc6acc200, dst=0xe8980b98, ro=0x0) at /usr/src/sys/net80211/ieee80211_output.c:406 #17 0xc092034b in bpfwrite (dev=0xc61df200, uio=0xe8980c58, ioflag=0) at /usr/src/sys/net/bpf.c:889 #18 0xc0806b4f in devfs_write_f (fp=0xc68c8310, uio=0xe8980c58, cred=0xc77d8e00, flags=0, td=0xc68586c0) at /usr/src/sys/fs/devfs/devfs_vnops.c:1509 #19 0xc08be3f7 in dofilewrite (td=0xc68586c0, fd=6, fp=0xc68c8310, auio=0xe8980c58, offset=-1, flags=0) at file.h:239 #20 0xc08be6e8 in kern_writev (td=0xc68586c0, fd=6, auio=0xe8980c58) at /usr/src/sys/kern/sys_generic.c:446 #21 0xc08be76f in write (td=0xc68586c0, uap=0xe8980cf8) at /usr/src/sys/kern/sys_generic.c:362 #22 0xc0bb3a35 in syscall (frame=0xe8980d38) at /usr/src/sys/i386/i386/trap.c:1073 #23 0xc0b96ab0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #24 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) From rihad at mail.ru Mon Oct 5 11:29:06 2009 From: rihad at mail.ru (rihad) Date: Mon Oct 5 11:29:13 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091005110726.GA62598@onelab2.iet.unipi.it> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> Message-ID: <4AC9D87E.7000005@mail.ru> Luigi Rizzo wrote: > On Mon, Oct 05, 2009 at 03:52:39PM +0500, rihad wrote: >> Eugene Grosbein wrote: >>> On Mon, Oct 05, 2009 at 02:28:58PM +0500, rihad wrote: >>> >>>> Still not sure why increasing queue size as high as I want doesn't >>>> completely eliminate drops. >>> The goal is to make sources of traffic to slow down, this is the only >>> way to descrease drops - any finite queue may be overhelmed with traffic. >>> Taildrop does not really help with this. GRED does much better. >>> >> Alright, so I changed to gred by adding to each config command: >> ipfw ... gred 0.002/900/1000/0.1 queue 1000 >> and reconfigured. Still around 300-400 drops per second, which was >> typical at this load level before with taildrop anyway. There are around >> 3-5 mbit/s being wasted according to systat -ifstat. >> >> Should I now increase slots to 5-10-20k? >> Very strange. >> >> "ipfw pipe show" correctly shows that gred is at work. For example: >> 00512: 512.000 Kbit/s 0 ms 1000 sl. 79 queues (64 buckets) >> GRED w_q 0.001999 min_th 900 max_th 1000 max_p 0.099991 >> mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 >> ... > > you keep omitting the important info i.e. whether individual > pipes have drops, significant queue lenghts and so on. > Sorry. Almost everyone has 0 in the last Drp column, but some have above zero. I'm not just sure how this can be helpful to anyone. 05120: 5.120 Mbit/s 0 ms 5000 sl. 66 queues (64 buckets) GRED w_q 0.001999 min_th 4500 max_th 5000 max_p 0.099991 mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 ip 0.0.0.0/0 1 131 0 0 0 1 ip 0.0.0.0/0 39 53360 0 0 0 2 ip 0.0.0.0/0 382206 418022848 0 0 0 3 ip 0.0.0.0/0 34 2008 0 0 0 4 ip 0.0.0.0/0 4868510 6277077787 15 20452 9 5 ip 0.0.0.0/0 14 16675 0 0 0 5 ip 0.0.0.0/0 3 4158 0 0 0 6 ip 0.0.0.0/0 38 43576 0 0 0 7 ip 0.0.0.0/0 1265954 1475400663 0 0 0 8 ip 0.0.0.0/0 1081461 1247681879 0 0 749 9 ip 0.0.0.0/0 6186589 8737048919 0 0 19243 10 ip 0.0.0.0/0 21607 5636447 0 0 5 11 ip 0.0.0.0/0 437 94576 0 0 0 12 ip 0.0.0.0/0 22915 18634779 0 0 0 13 ip 0.0.0.0/0 557988 688051579 0 0 0 14 ip 0.0.0.0/0 50339 65685647 0 0 0 15 ip 0.0.0.0/0 554835 546223485 0 0 140 16 ip 0.0.0.0/0 32 13104 0 0 0 17 ip 0.0.0.0/0 2034099 2719966792 0 0 0 18 ip 0.0.0.0/0 282 36551 0 0 0 19 ip 0.0.0.0/0 8351766 8947643162 0 0 0 20 ip 0.0.0.0/0 4 624 0 0 0 21 ip 0.0.0.0/0 22391 29922375 0 0 0 22 ip 0.0.0.0/0 9 424 0 0 0 23 ip 0.0.0.0/0 750322 935365326 0 0 0 24 ip 0.0.0.0/0 1 40 0 0 0 25 ip 0.0.0.0/0 3617690 3501375619 0 0 602 26 ip 0.0.0.0/0 12116 12039435 0 0 0 27 ip 0.0.0.0/0 524311 653399507 0 0 8 28 ip 0.0.0.0/0 3 417 0 0 0 29 ip 0.0.0.0/0 16 2034 0 0 0 30 ip 0.0.0.0/0 64 82661 3 4432 0 31 ip 0.0.0.0/0 946389 1175221367 0 0 66 32 ip 0.0.0.0/0 1 168 0 0 0 32 ip 0.0.0.0/0 28 41776 0 0 0 33 ip 0.0.0.0/0 6 6433 0 0 0 34 ip 0.0.0.0/0 1 536 0 0 0 35 ip 0.0.0.0/0 2021 2641048 0 0 0 36 ip 0.0.0.0/0 350 264039 0 0 0 37 ip 0.0.0.0/0 167578 137763107 0 0 0 38 ip 0.0.0.0/0 250404 128905757 0 0 0 39 ip 0.0.0.0/0 385139 287006012 0 0 0 40 ip 0.0.0.0/0 49 68696 0 0 0 41 ip 0.0.0.0/0 23 1813 0 0 0 42 ip 0.0.0.0/0 129 135256 0 0 0 43 ip 0.0.0.0/0 3232 2191027 0 0 0 44 ip 0.0.0.0/0 27935157 24307287646 0 0 18802 45 ip 0.0.0.0/0 2166 212635 0 0 0 46 ip 0.0.0.0/0 1127307 1392467620 0 0 3 47 ip 0.0.0.0/0 1216900 1258200836 0 0 0 48 ip 0.0.0.0/0 2 2984 1 1492 0 49 ip 0.0.0.0/0 1 112 0 0 0 50 ip 0.0.0.0/0 1409 326389 0 0 0 51 ip 0.0.0.0/0 46674 47291021 10 14920 0 52 ip 0.0.0.0/0 86667 66834983 0 0 0 53 ip 0.0.0.0/0 434998 302827189 0 0 0 54 ip 0.0.0.0/0 542 277669 0 0 0 55 ip 0.0.0.0/0 1088072 919495021 0 0 0 56 ip 0.0.0.0/0 64 81240 0 0 0 57 ip 0.0.0.0/0 41028 59193278 0 0 0 58 ip 0.0.0.0/0 1 210 0 0 0 59 ip 0.0.0.0/0 4 310 0 0 0 60 ip 0.0.0.0/0 2 2984 0 0 0 61 ip 0.0.0.0/0 42874 36616688 0 0 0 62 ip 0.0.0.0/0 4 498 0 0 0 63 ip 0.0.0.0/0 530137 717027403 0 0 0 From eugen at kuzbass.ru Mon Oct 5 11:30:40 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Mon Oct 5 11:30:47 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AC9C88A.5050509@mail.ru> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <20091005100446.GA60244@onelab2.iet.unipi.it> <20091005100532.GC73335@svzserv.kemerovo.su> <4AC9C88A.5050509@mail.ru> Message-ID: <20091005113037.GA77999@svzserv.kemerovo.su> On Mon, Oct 05, 2009 at 03:20:58PM +0500, rihad wrote: > >>>Taildrop does not really help with this. GRED does much better. > >>i think the first problem here is figure out _why_ we have > >>the drops, as the original poster said that queues are configured > >>with a very large amount of buffer (and i think there is a > >>misconfiguration somewhere because the mbuf stats do not make > >>sense) > > > >That may be very simple, f.e. wide uplink channel and policy that > >dictates slower client speeds. Any taildrop queue would drop lots > >of packets. > > > If uplink is e.g. 100 mbit/s, but data is fed to client by dummynet at 1 > mbit/s, doesn't the _client's_ TCP software know to slow things down to > not overwhelm 1 mbit/s? That's not client's TCP software feeding your router with traffic but server side. > Where has TCP slow-start gone? My router box > isn't some application proxy that starts downloading at full 100 mbit/s > thus quickly filling client's 1 mbit/s link. It's just a router. While there is no or little competition for bandwidth from the router to clients, TCP would work just fine. I suspect your shaping policy makes heavy competition between clients. In this case, TCP behaves not-so-well without help of router's good shaping algorythms and taildrop is not good one. > Although it doesn't yet make sense to me, I'll try going to GRED soon. "Works for me" :-) Eugene Grosbein From eugen at kuzbass.ru Mon Oct 5 11:46:39 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Mon Oct 5 11:46:45 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AC8BF3B.10601@mail.ru> References: <4AC8A76B.3050502@mail.ru> <20091004144909.GA42503@onelab2.iet.unipi.it> <4AC8B6E3.2070101@mail.ru> <20091004151518.GB42877@onelab2.iet.unipi.it> <4AC8BF3B.10601@mail.ru> Message-ID: <20091005114636.GB77999@svzserv.kemerovo.su> On Sun, Oct 04, 2009 at 08:28:59PM +0500, rihad wrote: > Thanks for the tip. although I took an easier route by simply doing > "ipfw add allow ip from any to any" before the pipe rules, and the buf > drop rate instantly became 0. So the problem is dummynet/ipfw. You should also estimate volume of non-TCP traffic that is generally has not flow control capabilities of TCP. Or, try something like this: ipfw add 100 skipto 200 tcp from any to any # direct only TCP to dummynet ipfw add 150 allow ip from any to any # pass non-TCP ipfw add 200 ... # here dummynet rules go And take a look at drop counters. Eugene Grosbein From rihad at mail.ru Mon Oct 5 11:48:03 2009 From: rihad at mail.ru (rihad) Date: Mon Oct 5 11:48:11 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091005113037.GA77999@svzserv.kemerovo.su> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <20091005100446.GA60244@onelab2.iet.unipi.it> <20091005100532.GC73335@svzserv.kemerovo.su> <4AC9C88A.5050509@mail.ru> <20091005113037.GA77999@svzserv.kemerovo.su> Message-ID: <4AC9DCEF.7080502@mail.ru> Eugene Grosbein wrote: > On Mon, Oct 05, 2009 at 03:20:58PM +0500, rihad wrote: > >>>>> Taildrop does not really help with this. GRED does much better. >>>> i think the first problem here is figure out _why_ we have >>>> the drops, as the original poster said that queues are configured >>>> with a very large amount of buffer (and i think there is a >>>> misconfiguration somewhere because the mbuf stats do not make >>>> sense) >>> That may be very simple, f.e. wide uplink channel and policy that >>> dictates slower client speeds. Any taildrop queue would drop lots >>> of packets. >>> >> If uplink is e.g. 100 mbit/s, but data is fed to client by dummynet at 1 >> mbit/s, doesn't the _client's_ TCP software know to slow things down to >> not overwhelm 1 mbit/s? > > That's not client's TCP software feeding your router with traffic > but server side. > Yup, I meant client-side decreasing congestion window, delaying ACKs etc. etc., typical for TCP congestion control. Or...? GRED didn't solve the problem :( From rihad at mail.ru Mon Oct 5 11:50:13 2009 From: rihad at mail.ru (rihad) Date: Mon Oct 5 11:50:19 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091005113037.GA77999@svzserv.kemerovo.su> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <20091005100446.GA60244@onelab2.iet.unipi.it> <20091005100532.GC73335@svzserv.kemerovo.su> <4AC9C88A.5050509@mail.ru> <20091005113037.GA77999@svzserv.kemerovo.su> Message-ID: <4AC9DD72.9060802@mail.ru> Eugene Grosbein wrote: > On Mon, Oct 05, 2009 at 03:20:58PM +0500, rihad wrote: >> Where has TCP slow-start gone? My router box >> isn't some application proxy that starts downloading at full 100 mbit/s >> thus quickly filling client's 1 mbit/s link. It's just a router. > > While there is no or little competition for bandwidth from the router > to clients, TCP would work just fine. I suspect your shaping policy > makes heavy competition between clients. In this case, TCP behaves > not-so-well without help of router's good shaping algorythms > and taildrop is not good one. > Nothing fancy (i.e. no competition). Only tons of per-user pipes simulating the given throughput. From rizzo at iet.unipi.it Mon Oct 5 11:57:40 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Mon Oct 5 11:57:46 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AC9D87E.7000005@mail.ru> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> Message-ID: <20091005120418.GA63131@onelab2.iet.unipi.it> On Mon, Oct 05, 2009 at 04:29:02PM +0500, rihad wrote: > Luigi Rizzo wrote: ... > >you keep omitting the important info i.e. whether individual > >pipes have drops, significant queue lenghts and so on. > > > Sorry. Almost everyone has 0 in the last Drp column, but some have above > zero. I'm not just sure how this can be helpful to anyone. because you were complaining about 'dummynet causing drops and waste of bandwidth'. Now, drops could be due to either 1) some saturation in the dummynet machine (memory shortage, cpu shortage, etc.) which cause unwanted drops; 2) intentional drops introduced by dummynet because a flow exceeds its queue size. These drops are those shown in the 'Drop' column in 'ipfw pipe show' (they are cumulative, so you should do an 'ipfw pipe delete; ipfw pipe 5120 config ...' whenever you want to re-run the stats, or compute the differences between subsequent reads, to figure out what happens. If all drops you are seeing are of type 2, then there is nothing you can do to remove them: you set a bandwidth limit, the client is sending faster than it should, perhaps with UDP so even RED/GRED won't help you, and you see the drops once the queue starts to fill up. Examples below: the entries in bucket 4 and 44 If you are seeing drops that are not listed in 'pipe show' then yun need to investigate where the packets are lost, again it could be on the output queue of the interface (due to the burstiness introduced by dummynet), or shortage of mbufs (but this did not seem to be the case from your previous stats) or something else. It's all up to you to run measurements, possibly without omitting potentially significant data (e.g. sysctl -a net.inet.ip) or making assumptions (e.g. you have configured 5000 slots per queue, but with only 50k mbufs in total there is no chance to guarantee 5000 slots to each queue -- all you will achieve is give a lot of slots to the greedy nodes, and very little to the other ones) cheers luigi > 05120: 5.120 Mbit/s 0 ms 5000 sl. 66 queues (64 buckets) > GRED w_q 0.001999 min_th 4500 max_th 5000 max_p 0.099991 > mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 0 ip 0.0.0.0/0 1 131 0 0 0 > 1 ip 0.0.0.0/0 39 53360 0 0 0 > 2 ip 0.0.0.0/0 382206 418022848 0 > 0 0 > 3 ip 0.0.0.0/0 34 2008 0 0 0 > 4 ip 0.0.0.0/0 4868510 6277077787 15 > 20452 9 > 5 ip 0.0.0.0/0 14 16675 0 0 0 > 5 ip 0.0.0.0/0 3 4158 0 0 0 > 6 ip 0.0.0.0/0 38 43576 0 0 0 > 7 ip 0.0.0.0/0 1265954 1475400663 0 > 0 0 > 8 ip 0.0.0.0/0 1081461 1247681879 0 > 0 749 > 9 ip 0.0.0.0/0 6186589 8737048919 0 > 0 19243 > 10 ip 0.0.0.0/0 21607 5636447 0 0 5 > 11 ip 0.0.0.0/0 437 94576 0 0 0 > 12 ip 0.0.0.0/0 22915 18634779 0 0 0 > 13 ip 0.0.0.0/0 557988 688051579 0 > 0 0 > 14 ip 0.0.0.0/0 50339 65685647 0 0 0 > 15 ip 0.0.0.0/0 554835 546223485 0 > 0 140 > 16 ip 0.0.0.0/0 32 13104 0 0 0 > 17 ip 0.0.0.0/0 2034099 2719966792 0 > 0 0 > 18 ip 0.0.0.0/0 282 36551 0 0 0 > 19 ip 0.0.0.0/0 8351766 8947643162 0 > 0 0 > 20 ip 0.0.0.0/0 4 624 0 0 0 > 21 ip 0.0.0.0/0 22391 29922375 0 0 0 > 22 ip 0.0.0.0/0 9 424 0 0 0 > 23 ip 0.0.0.0/0 750322 935365326 0 > 0 0 > 24 ip 0.0.0.0/0 1 40 0 0 0 > 25 ip 0.0.0.0/0 3617690 3501375619 0 > 0 602 > 26 ip 0.0.0.0/0 12116 12039435 0 0 0 > 27 ip 0.0.0.0/0 524311 653399507 0 > 0 8 > 28 ip 0.0.0.0/0 3 417 0 0 0 > 29 ip 0.0.0.0/0 16 2034 0 0 0 > 30 ip 0.0.0.0/0 64 82661 3 4432 0 > 31 ip 0.0.0.0/0 946389 1175221367 0 > 0 66 > 32 ip 0.0.0.0/0 1 168 0 0 0 > 32 ip 0.0.0.0/0 28 41776 0 0 0 > 33 ip 0.0.0.0/0 6 6433 0 0 0 > 34 ip 0.0.0.0/0 1 536 0 0 0 > 35 ip 0.0.0.0/0 2021 2641048 0 0 0 > 36 ip 0.0.0.0/0 350 264039 0 0 0 > 37 ip 0.0.0.0/0 167578 137763107 0 > 0 0 > 38 ip 0.0.0.0/0 250404 128905757 0 > 0 0 > 39 ip 0.0.0.0/0 385139 287006012 0 > 0 0 > 40 ip 0.0.0.0/0 49 68696 0 0 0 > 41 ip 0.0.0.0/0 23 1813 0 0 0 > 42 ip 0.0.0.0/0 129 135256 0 0 0 > 43 ip 0.0.0.0/0 3232 2191027 0 0 0 > 44 ip 0.0.0.0/0 27935157 24307287646 0 > 0 18802 > 45 ip 0.0.0.0/0 2166 212635 0 0 0 > 46 ip 0.0.0.0/0 1127307 1392467620 0 > 0 3 > 47 ip 0.0.0.0/0 1216900 1258200836 0 > 0 0 > 48 ip 0.0.0.0/0 2 2984 1 1492 0 > 49 ip 0.0.0.0/0 1 112 0 0 0 > 50 ip 0.0.0.0/0 1409 326389 0 0 0 > 51 ip 0.0.0.0/0 46674 47291021 10 14920 0 > 52 ip 0.0.0.0/0 86667 66834983 0 0 0 > 53 ip 0.0.0.0/0 434998 302827189 0 > 0 0 > 54 ip 0.0.0.0/0 542 277669 0 0 0 > 55 ip 0.0.0.0/0 1088072 919495021 0 > 0 0 > 56 ip 0.0.0.0/0 64 81240 0 0 0 > 57 ip 0.0.0.0/0 41028 59193278 0 0 0 > 58 ip 0.0.0.0/0 1 210 0 0 0 > 59 ip 0.0.0.0/0 4 310 0 0 0 > 60 ip 0.0.0.0/0 2 2984 0 0 0 > 61 ip 0.0.0.0/0 42874 36616688 0 0 0 > 62 ip 0.0.0.0/0 4 498 0 0 0 > 63 ip 0.0.0.0/0 530137 717027403 0 > 0 0 From eugen at kuzbass.ru Mon Oct 5 12:00:59 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Mon Oct 5 12:01:05 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AC9DD72.9060802@mail.ru> References: <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <20091005100446.GA60244@onelab2.iet.unipi.it> <20091005100532.GC73335@svzserv.kemerovo.su> <4AC9C88A.5050509@mail.ru> <20091005113037.GA77999@svzserv.kemerovo.su> <4AC9DD72.9060802@mail.ru> Message-ID: <20091005120057.GA79942@svzserv.kemerovo.su> On Mon, Oct 05, 2009 at 04:50:10PM +0500, rihad wrote: > >>Where has TCP slow-start gone? My router box > >>isn't some application proxy that starts downloading at full 100 mbit/s > >>thus quickly filling client's 1 mbit/s link. It's just a router. > > > >While there is no or little competition for bandwidth from the router > >to clients, TCP would work just fine. I suspect your shaping policy > >makes heavy competition between clients. In this case, TCP behaves > >not-so-well without help of router's good shaping algorythms > >and taildrop is not good one. > > > > Nothing fancy (i.e. no competition). Only tons of per-user pipes > simulating the given throughput. You've mentioned previously: "The pipes are fine, each normally having 100-120 concurrent consumers (i.e. active users)." This IS competition between TCP flows inside each pipe. Eugene Grosbein From rihad at mail.ru Mon Oct 5 12:12:14 2009 From: rihad at mail.ru (rihad) Date: Mon Oct 5 12:12:20 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091005120418.GA63131@onelab2.iet.unipi.it> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> Message-ID: <4AC9E29B.6080908@mail.ru> Luigi Rizzo wrote: > On Mon, Oct 05, 2009 at 04:29:02PM +0500, rihad wrote: >> Luigi Rizzo wrote: > ... >>> you keep omitting the important info i.e. whether individual >>> pipes have drops, significant queue lenghts and so on. >>> >> Sorry. Almost everyone has 0 in the last Drp column, but some have above >> zero. I'm not just sure how this can be helpful to anyone. > > because you were complaining about 'dummynet causing drops and > waste of bandwidth'. > Now, drops could be due to either > 1) some saturation in the dummynet machine (memory shortage, cpu > shortage, etc.) which cause unwanted drops; > I too think the box is hitting some other global limit and dropping packets. If not, then how come that between 4a.m. and 10a.m. when the traffic load is at 250-330 mbit/s there isn't a single drop? > 2) intentional drops introduced by dummynet because a flow exceeds > its queue size. These drops are those shown in the 'Drop' > column in 'ipfw pipe show' (they are cumulative, so you > should do an 'ipfw pipe delete; ipfw pipe 5120 config ...' > whenever you want to re-run the stats, or compute the > differences between subsequent reads, to figure out what > happens. > > If all drops you are seeing are of type 2, then there is nothing > you can do to remove them: you set a bandwidth limit, the > client is sending faster than it should, perhaps with UDP > so even RED/GRED won't help you, and you see the drops > once the queue starts to fill up. > Examples below: the entries in bucket 4 and 44 > Then I guess I'm left with increasing slots and see how it goes. Currently it's set to 10000 for each pipe. Thanks for yours and Eugene's efforts, I appreciate it. > If you are seeing drops that are not listed in 'pipe show' > then yun need to investigate where the packets are lost, > again it could be on the output queue of the interface > (due to the burstiness introduced by dummynet), or shortage > of mbufs (but this did not seem to be the case from your > previous stats) or something else. > This indeed is not a problem, proved by the fact that, like I said, short-circuiting "ipfw allow ip from any to any" before dummynet pipe rules instantly eliminates all drops, and bce0 and bce1 load evens out (bce0 used for input, and bce1 for output). > It's all up to you to run measurements, possibly > without omitting potentially significant data > (e.g. sysctl -a net.inet.ip) > or making assumptions (e.g. you have configured > 5000 slots per queue, but with only 50k mbufs in total > there is no chance to guarantee 5000 slots to each > queue -- all you will achieve is give a lot of slots > to the greedy nodes, and very little to the other ones) > Well, I've been monitoring this stuff. It has never reached above 20000 mbufs (111111 is the current limit). From rihad at mail.ru Mon Oct 5 12:18:32 2009 From: rihad at mail.ru (rihad) Date: Mon Oct 5 12:18:39 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091005120057.GA79942@svzserv.kemerovo.su> References: <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <20091005100446.GA60244@onelab2.iet.unipi.it> <20091005100532.GC73335@svzserv.kemerovo.su> <4AC9C88A.5050509@mail.ru> <20091005113037.GA77999@svzserv.kemerovo.su> <4AC9DD72.9060802@mail.ru> <20091005120057.GA79942@svzserv.kemerovo.su> Message-ID: <4AC9E415.9040801@mail.ru> Eugene Grosbein wrote: > On Mon, Oct 05, 2009 at 04:50:10PM +0500, rihad wrote: > >>>> Where has TCP slow-start gone? My router box >>>> isn't some application proxy that starts downloading at full 100 mbit/s >>>> thus quickly filling client's 1 mbit/s link. It's just a router. >>> While there is no or little competition for bandwidth from the router >>> to clients, TCP would work just fine. I suspect your shaping policy >>> makes heavy competition between clients. In this case, TCP behaves >>> not-so-well without help of router's good shaping algorythms >>> and taildrop is not good one. >>> >> Nothing fancy (i.e. no competition). Only tons of per-user pipes >> simulating the given throughput. > > You've mentioned previously: "The pipes are fine, each normally having > 100-120 concurrent consumers (i.e. active users)." > This IS competition between TCP flows inside each pipe. > Well, each user gets instantiated with a new copy of the pipe. Each such user counts towards the limit imposed by hash_size*max_chain_len for that pipe only. It would have been competition had I used dst-ip dst-ip 0xffffff00 or similar and not dst-ip 0xffffffff, _then_ all 256 users (determined by the mask) would compete for the pipe's bandwidth. So the only competition is in the uplink at our main Cisco, I guess. From rizzo at iet.unipi.it Mon Oct 5 12:25:51 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Mon Oct 5 12:25:57 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AC9E29B.6080908@mail.ru> References: <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> Message-ID: <20091005123230.GA64167@onelab2.iet.unipi.it> On Mon, Oct 05, 2009 at 05:12:11PM +0500, rihad wrote: > Luigi Rizzo wrote: > >On Mon, Oct 05, 2009 at 04:29:02PM +0500, rihad wrote: > >>Luigi Rizzo wrote: > >... > >>>you keep omitting the important info i.e. whether individual > >>>pipes have drops, significant queue lenghts and so on. > >>> > >>Sorry. Almost everyone has 0 in the last Drp column, but some have above > >>zero. I'm not just sure how this can be helpful to anyone. > > > >because you were complaining about 'dummynet causing drops and > >waste of bandwidth'. > >Now, drops could be due to either > >1) some saturation in the dummynet machine (memory shortage, cpu > > shortage, etc.) which cause unwanted drops; > > > I too think the box is hitting some other global limit and dropping > packets. If not, then how come that between 4a.m. and 10a.m. when the > traffic load is at 250-330 mbit/s there isn't a single drop? there may be different reasons, e.g. the big offenders were idle when you saw no drops. You still do not have enough information on which packets are dropped and where, so you cannot prove your assumptions. Also, below: 1. increasing the queue size won't help at all. Those who overflow a queue of 1000 slots will also overflow a queue of 10k slots. 2. your test with 'ipfw allow ip from any to any' does not prove that the interface queue is not saturating, because you also remove the burstiness that dummynet introduces, and so the queue is driven differently. good luck luigi > >2) intentional drops introduced by dummynet because a flow exceeds > > its queue size. These drops are those shown in the 'Drop' > > column in 'ipfw pipe show' (they are cumulative, so you > > should do an 'ipfw pipe delete; ipfw pipe 5120 config ...' > > whenever you want to re-run the stats, or compute the > > differences between subsequent reads, to figure out what > > happens. > > > >If all drops you are seeing are of type 2, then there is nothing > >you can do to remove them: you set a bandwidth limit, the > >client is sending faster than it should, perhaps with UDP > >so even RED/GRED won't help you, and you see the drops > >once the queue starts to fill up. > >Examples below: the entries in bucket 4 and 44 > > > Then I guess I'm left with increasing slots and see how it goes. > Currently it's set to 10000 for each pipe. Thanks for yours and Eugene's > efforts, I appreciate it. > > >If you are seeing drops that are not listed in 'pipe show' > >then yun need to investigate where the packets are lost, > >again it could be on the output queue of the interface > >(due to the burstiness introduced by dummynet), or shortage > >of mbufs (but this did not seem to be the case from your > >previous stats) or something else. > > > This indeed is not a problem, proved by the fact that, like I said, > short-circuiting "ipfw allow ip from any to any" before dummynet pipe > rules instantly eliminates all drops, and bce0 and bce1 load evens out > (bce0 used for input, and bce1 for output). > > >It's all up to you to run measurements, possibly > >without omitting potentially significant data > >(e.g. sysctl -a net.inet.ip) > >or making assumptions (e.g. you have configured > >5000 slots per queue, but with only 50k mbufs in total > >there is no chance to guarantee 5000 slots to each > >queue -- all you will achieve is give a lot of slots > >to the greedy nodes, and very little to the other ones) > > > Well, I've been monitoring this stuff. It has never reached above 20000 > mbufs (111111 is the current limit). From rihad at mail.ru Mon Oct 5 13:08:50 2009 From: rihad at mail.ru (rihad) Date: Mon Oct 5 13:08:57 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091005123230.GA64167@onelab2.iet.unipi.it> References: <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> Message-ID: <4AC9EFDF.4080302@mail.ru> Luigi Rizzo wrote: > On Mon, Oct 05, 2009 at 05:12:11PM +0500, rihad wrote: >> Luigi Rizzo wrote: >>> On Mon, Oct 05, 2009 at 04:29:02PM +0500, rihad wrote: >>>> Luigi Rizzo wrote: >>> ... >>>>> you keep omitting the important info i.e. whether individual >>>>> pipes have drops, significant queue lenghts and so on. >>>>> >>>> Sorry. Almost everyone has 0 in the last Drp column, but some have above >>>> zero. I'm not just sure how this can be helpful to anyone. >>> because you were complaining about 'dummynet causing drops and >>> waste of bandwidth'. >>> Now, drops could be due to either >>> 1) some saturation in the dummynet machine (memory shortage, cpu >>> shortage, etc.) which cause unwanted drops; >>> >> I too think the box is hitting some other global limit and dropping >> packets. If not, then how come that between 4a.m. and 10a.m. when the >> traffic load is at 250-330 mbit/s there isn't a single drop? > > there may be different reasons, e.g. the big offenders were > idle when you saw no drops. You still do not have enough > information on which packets are dropped and where, > so you cannot prove your assumptions. > > Also, below: > 1. increasing the queue size won't help at all. Those > who overflow a queue of 1000 slots will also overflow > a queue of 10k slots. > > 2. your test with 'ipfw allow ip from any to any' does not > prove that the interface queue is not saturating, because > you also remove the burstiness that dummynet introduces, > and so the queue is driven differently. > There's one thing I noticed: net.inet.ip.dummynet.io_pkt_drop doesn't grow! But still around 400 packets dropped per second. net.inet.ip.dummynet.tick_lost is always zero net.inet.ip.dummynet.tick_diff: grows at about 50 per second. net.inet.ip.dummynet.tick_adjustment: grows at about 5 per second. How do I investigate and fix this burstiness issue? $ netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll bce0 1500 00:1d:09:xx:xx:xx 24777049059 0 75426020 0 0 bce0 1500 xx.xx.xx.xx/xx my.hostname 159293969 - 75282225 - - bce1 1500 00:1d:09:xx:xx:xx 724725 0 24514919344 0 0 bce1 1500 192.168.94.0 local.hostname 656243 - 83024869 - - From eugen at kuzbass.ru Mon Oct 5 13:56:36 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Mon Oct 5 13:56:43 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AC9E415.9040801@mail.ru> References: <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <20091005100446.GA60244@onelab2.iet.unipi.it> <20091005100532.GC73335@svzserv.kemerovo.su> <4AC9C88A.5050509@mail.ru> <20091005113037.GA77999@svzserv.kemerovo.su> <4AC9DD72.9060802@mail.ru> <20091005120057.GA79942@svzserv.kemerovo.su> <4AC9E415.9040801@mail.ru> Message-ID: <20091005135632.GA89194@svzserv.kemerovo.su> On Mon, Oct 05, 2009 at 05:18:29PM +0500, rihad wrote: > >You've mentioned previously: "The pipes are fine, each normally having > >100-120 concurrent consumers (i.e. active users)." > >This IS competition between TCP flows inside each pipe. > > > Well, each user gets instantiated with a new copy of the pipe. Each such > user counts towards the limit imposed by hash_size*max_chain_len for > that pipe only. It would have been competition had I used dst-ip dst-ip > 0xffffff00 or similar and not dst-ip 0xffffffff, _then_ all 256 users > (determined by the mask) would compete for the pipe's bandwidth. So the > only competition is in the uplink at our main Cisco, I guess. Hmm, yes, you are rigth. I've missed 'mask'. Try to disable net.inet.ip.dummynet.io_fast to see if there is a bug in 'fast' dummynet mode. Eugene Grosbein From rihad at mail.ru Mon Oct 5 14:03:54 2009 From: rihad at mail.ru (rihad) Date: Mon Oct 5 14:04:01 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091005135632.GA89194@svzserv.kemerovo.su> References: <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <20091005100446.GA60244@onelab2.iet.unipi.it> <20091005100532.GC73335@svzserv.kemerovo.su> <4AC9C88A.5050509@mail.ru> <20091005113037.GA77999@svzserv.kemerovo.su> <4AC9DD72.9060802@mail.ru> <20091005120057.GA79942@svzserv.kemerovo.su> <4AC9E415.9040801@mail.ru> <20091005135632.GA89194@svzserv.kemerovo.su> Message-ID: <4AC9FCC7.1080108@mail.ru> Eugene Grosbein wrote: > Try to disable net.inet.ip.dummynet.io_fast to see if there is a bug > in 'fast' dummynet mode. > Already tried that, no difference. Interestingly, now I checked sysctls and found out that net.inet.ip.dummynet.io_pkt_fast counter is still growing despite io_fast being disabled. From eugen at kuzbass.ru Mon Oct 5 14:04:15 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Mon Oct 5 14:04:21 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AC9EFDF.4080302@mail.ru> References: <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> Message-ID: <20091005140409.GB89194@svzserv.kemerovo.su> On Mon, Oct 05, 2009 at 06:08:47PM +0500, rihad wrote: > How do I investigate and fix this burstiness issue? Please also show: sysctl net.isr sysctl net.inet.ip.intr_queue_maxlen Eugene Grosbein From rihad at mail.ru Mon Oct 5 14:30:20 2009 From: rihad at mail.ru (rihad) Date: Mon Oct 5 14:30:27 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091005140409.GB89194@svzserv.kemerovo.su> References: <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <20091005140409.GB89194@svzserv.kemerovo.su> Message-ID: <4ACA02F7.6040409@mail.ru> Eugene Grosbein wrote: > On Mon, Oct 05, 2009 at 06:08:47PM +0500, rihad wrote: > >> How do I investigate and fix this burstiness issue? > > Please also show: > > sysctl net.isr > sysctl net.inet.ip.intr_queue_maxlen > net.isr.swi_count: 65461359 net.isr.drop: 0 net.isr.queued: 32843752 net.isr.deferred: 0 net.isr.directed: -723075002 net.isr.count: -723074001 net.isr.direct: 1 net.inet.ip.intr_queue_maxlen: 50 From oberman at es.net Mon Oct 5 14:38:39 2009 From: oberman at es.net (Kevin Oberman) Date: Mon Oct 5 14:38:45 2009 Subject: Unusual TCP options can cause FreeBSD to issue a reset In-Reply-To: Your message of "Mon, 05 Oct 2009 10:24:33 +0200." <4AC9AD41.2070200@freebsd.org> Message-ID: <20091005143837.C370F1CC2E@ptavv.es.net> > Date: Mon, 05 Oct 2009 10:24:33 +0200 > From: Andre Oppermann > > Kevin Oberman wrote: > > I have a system that is unable to connect to a FreeBSD system due to > > the odd formatting of the TCP options. The options contains only the > > timestamp which, if recommendations in RFC1323 are followed, are > > preceded by two NOP bytes to put the timestamp values on 4 byte > > boundaries. > > > > This system sends the 12 byte timestamp option alone, followed by two > > zero bytes to pad it. This meets the requirements of RFC793 and 1323 is > > explicit that stacks must accept this, even though it results in > > sub-optimal performance and does not meet the recommendations in 1323 > > appendix A. > > Just this alone should not cause a reset from FreeBSD. > > > Any idea if this is hard to fix? I see in on both 7.2 and 8.0. > > Can you post a detailed tcpdump of a failing connect? And please enable > net.inet.tcp.log_debug which should give a better explanation on why > FreeBSD thinks the connection is bad. Thanks!. The debug output made the issue clear and it is not a FreeBSD problem. It is with the remote system and the timestamps used, I see the following timestamps: SYN----->159082 0 SYNACK-->57062695 159082 ACK----->159082 0 Clearly, this is bogus. Sorry for the noise and the bad analysis on Friday. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From eugen at kuzbass.ru Mon Oct 5 14:50:40 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Mon Oct 5 14:50:47 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACA02F7.6040409@mail.ru> References: <20091005095600.GA73335@svzserv.kemerovo.su> <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <20091005140409.GB89194@svzserv.kemerovo.su> <4ACA02F7.6040409@mail.ru> Message-ID: <20091005145037.GA92519@svzserv.kemerovo.su> On Mon, Oct 05, 2009 at 07:30:15PM +0500, rihad wrote: > >>How do I investigate and fix this burstiness issue? > > > >Please also show: > > > >sysctl net.isr > >sysctl net.inet.ip.intr_queue_maxlen > > net.isr.swi_count: 65461359 > net.isr.drop: 0 > net.isr.queued: 32843752 > net.isr.deferred: 0 > net.isr.directed: -723075002 > net.isr.count: -723074001 > net.isr.direct: 1 > > net.inet.ip.intr_queue_maxlen: 50 What is CPU load in when the load is maximum? Eugene From rihad at mail.ru Mon Oct 5 15:07:21 2009 From: rihad at mail.ru (rihad) Date: Mon Oct 5 15:07:27 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091005145037.GA92519@svzserv.kemerovo.su> References: <20091005095600.GA73335@svzserv.kemerovo.su> <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <20091005140409.GB89194@svzserv.kemerovo.su> <4ACA02F7.6040409@mail.ru> <20091005145037.GA92519@svzserv.kemerovo.su> Message-ID: <4ACA0BA6.70706@mail.ru> Eugene Grosbein wrote: > On Mon, Oct 05, 2009 at 07:30:15PM +0500, rihad wrote: > >>>> How do I investigate and fix this burstiness issue? >>> Please also show: >>> >>> sysctl net.isr >>> sysctl net.inet.ip.intr_queue_maxlen >> net.isr.swi_count: 65461359 >> net.isr.drop: 0 >> net.isr.queued: 32843752 >> net.isr.deferred: 0 >> net.isr.directed: -723075002 >> net.isr.count: -723074001 >> net.isr.direct: 1 >> >> net.inet.ip.intr_queue_maxlen: 50 > > What is CPU load in when the load is maximum? > It has 2 quad-cores, so I'm not sure. Here's the output of top -S: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 1 171 ki31 0K 16K CPU7 7 120.2H 98.39% idle: cpu7 12 root 1 171 ki31 0K 16K CPU6 6 120.3H 95.75% idle: cpu6 16 root 1 171 ki31 0K 16K CPU2 2 115.5H 93.99% idle: cpu2 14 root 1 171 ki31 0K 16K CPU4 4 114.6H 91.89% idle: cpu4 18 root 1 171 ki31 0K 16K RUN 0 97.7H 88.96% idle: cpu0 13 root 1 171 ki31 0K 16K CPU5 5 117.5H 85.35% idle: cpu5 15 root 1 171 ki31 0K 16K CPU3 3 110.2H 79.79% idle: cpu3 29 root 1 -68 - 0K 16K WAIT 1 59.1H 54.05% irq256: bce0 17 root 1 171 ki31 0K 16K CPU1 1 63.5H 42.29% idle: cpu1 467 root 1 -68 - 0K 16K - 3 21.4H 11.57% dummynet 19 root 1 -32 - 0K 16K WAIT 4 268:29 3.66% swi4: clock sio 31 root 1 -68 - 0K 16K WAIT 2 310:19 2.98% irq257: bce1 30 root 1 -64 - 0K 16K WAIT 6 40:02 0.29% irq16: mfi0 3 root 1 -8 - 0K 16K - 5 55:42 0.00% g_up 4 root 1 -8 - 0K 16K - 1 51:22 0.00% g_down 22 root 1 44 - 0K 16K - 3 13:30 0.00% yarrow 21 root 1 -44 - 0K 16K WAIT 0 9:09 0.00% swi1: net 51 root 1 20 - 0K 16K syncer 2 7:25 0.00% syncer 599 root 1 44 0 5660K 1132K select 0 1:40 0.00% syslogd 52 root 1 -16 - 0K 16K sdflus 5 0:34 0.00% softdepflush 2 root 1 -8 - 0K 16K - 2 0:31 0.00% g_event From eugen at kuzbass.ru Mon Oct 5 15:42:41 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Mon Oct 5 15:42:48 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACA0BA6.70706@mail.ru> References: <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <20091005140409.GB89194@svzserv.kemerovo.su> <4ACA02F7.6040409@mail.ru> <20091005145037.GA92519@svzserv.kemerovo.su> <4ACA0BA6.70706@mail.ru> Message-ID: <20091005154236.GA95635@svzserv.kemerovo.su> On Mon, Oct 05, 2009 at 08:07:18PM +0500, rihad wrote: > >What is CPU load in when the load is maximum? > > > It has 2 quad-cores, so I'm not sure. Here's the output of top -S: There is a rumour about FreeBSD's shedulers... That they are not so good for 8 cores and that you may get MORE speed by disabling 4 cores if it's possible for your system. Or even using uniprocessor kernel. Only rumour, though :-) Eugene Grosbein From rihad at mail.ru Mon Oct 5 16:09:54 2009 From: rihad at mail.ru (rihad) Date: Mon Oct 5 16:10:01 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091005154236.GA95635@svzserv.kemerovo.su> References: <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <20091005140409.GB89194@svzserv.kemerovo.su> <4ACA02F7.6040409@mail.ru> <20091005145037.GA92519@svzserv.kemerovo.su> <4ACA0BA6.70706@mail.ru> <20091005154236.GA95635@svzserv.kemerovo.su> Message-ID: <4ACA1A4D.4070801@mail.ru> Eugene Grosbein wrote: > On Mon, Oct 05, 2009 at 08:07:18PM +0500, rihad wrote: > >>> What is CPU load in when the load is maximum? >>> >> It has 2 quad-cores, so I'm not sure. Here's the output of top -S: > > There is a rumour about FreeBSD's shedulers... > That they are not so good for 8 cores and that you may get MORE speed > by disabling 4 cores if it's possible for your system. > Or even using uniprocessor kernel. > > Only rumour, though :-) > I'd really like to try this as the last option ;-) It's 21:07 where I live, and we're again wasting 9-10 mbit/s w/ 4k users online. systat -ifstat: bce1 in 0.000 Mb/s 0.003 Mb/s 49.004 MB out 470.102 Mb/s 470.102 Mb/s 22.637 TB bce0 in 479.754 Mb/s 479.754 Mb/s 22.858 TB out 0.148 Mb/s 0.207 Mb/s 6.950 GB From julian at elischer.org Mon Oct 5 17:03:14 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Oct 5 17:03:22 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091005100446.GA60244@onelab2.iet.unipi.it> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <20091005100446.GA60244@onelab2.iet.unipi.it> Message-ID: <4ACA26D4.2080102@elischer.org> Luigi Rizzo wrote: >> Taildrop does not really help with this. GRED does much better. > > i think the first problem here is figure out _why_ we have > the drops, as the original poster said that queues are configured > with a very large amount of buffer (and i think there is a > misconfiguration somewhere because the mbuf stats do not make > sense) it all depends on the characteristics of the traffic you need different queue lengths if it is just a small number of high speeed sessions (and mayne a large number of slow speed sessions), or if it is a larger number of medium speed sessions. Is it possible to know what sessions are losing packets? From julian at elischer.org Mon Oct 5 17:18:09 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Oct 5 17:18:15 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AC9D87E.7000005@mail.ru> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> Message-ID: <4ACA2A52.4050704@elischer.org> rihad wrote: > Luigi Rizzo wrote: >> On Mon, Oct 05, 2009 at 03:52:39PM +0500, rihad wrote: >>> Eugene Grosbein wrote: >>>> On Mon, Oct 05, 2009 at 02:28:58PM +0500, rihad wrote: >>>> >>>>> Still not sure why increasing queue size as high as I want doesn't >>>>> completely eliminate drops. >>>> The goal is to make sources of traffic to slow down, this is the only >>>> way to descrease drops - any finite queue may be overhelmed with >>>> traffic. >>>> Taildrop does not really help with this. GRED does much better. >>>> >>> Alright, so I changed to gred by adding to each config command: >>> ipfw ... gred 0.002/900/1000/0.1 queue 1000 >>> and reconfigured. Still around 300-400 drops per second, which was >>> typical at this load level before with taildrop anyway. There are >>> around 3-5 mbit/s being wasted according to systat -ifstat. >>> >>> Should I now increase slots to 5-10-20k? >>> Very strange. >>> >>> "ipfw pipe show" correctly shows that gred is at work. For example: >>> 00512: 512.000 Kbit/s 0 ms 1000 sl. 79 queues (64 buckets) >>> GRED w_q 0.001999 min_th 900 max_th 1000 max_p 0.099991 >>> mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 >>> ... >> >> you keep omitting the important info i.e. whether individual >> pipes have drops, significant queue lenghts and so on. >> > Sorry. Almost everyone has 0 in the last Drp column, but some have above > zero. I'm not just sure how this can be helpful to anyone. This tells us there are just a few sessions with VERY LARGE WINDOWS that are trying to push the link too fast. They are flooding the firewall and geting all the drops. (unless the problem is that the hash/mask is putting a lot of session on the same slot.) > > 05120: 5.120 Mbit/s 0 ms 5000 sl. 66 queues (64 buckets) > GRED w_q 0.001999 min_th 4500 max_th 5000 max_p 0.099991 > mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 0 ip 0.0.0.0/0 1 131 0 0 0 > 1 ip 0.0.0.0/0 39 53360 0 0 0 > 2 ip 0.0.0.0/0 382206 418022848 0 0 0 > 3 ip 0.0.0.0/0 34 2008 0 0 0 > 4 ip 0.0.0.0/0 4868510 6277077787 15 > 20452 9 > 5 ip 0.0.0.0/0 14 16675 0 0 0 > 5 ip 0.0.0.0/0 3 4158 0 0 0 > 6 ip 0.0.0.0/0 38 43576 0 0 0 > 7 ip 0.0.0.0/0 1265954 1475400663 0 > 0 0 > 8 ip 0.0.0.0/0 1081461 1247681879 0 > 0 749 > 9 ip 0.0.0.0/0 6186589 8737048919 0 > 0 19243 > 10 ip 0.0.0.0/0 21607 5636447 0 0 5 > 11 ip 0.0.0.0/0 437 94576 0 0 0 > 12 ip 0.0.0.0/0 22915 18634779 0 0 0 > 13 ip 0.0.0.0/0 557988 688051579 0 0 0 > 14 ip 0.0.0.0/0 50339 65685647 0 0 0 > 15 ip 0.0.0.0/0 554835 546223485 0 0 140 > 16 ip 0.0.0.0/0 32 13104 0 0 0 > 17 ip 0.0.0.0/0 2034099 2719966792 0 > 0 0 > 18 ip 0.0.0.0/0 282 36551 0 0 0 > 19 ip 0.0.0.0/0 8351766 8947643162 0 > 0 0 > 20 ip 0.0.0.0/0 4 624 0 0 0 > 21 ip 0.0.0.0/0 22391 29922375 0 0 0 > 22 ip 0.0.0.0/0 9 424 0 0 0 > 23 ip 0.0.0.0/0 750322 935365326 0 0 0 > 24 ip 0.0.0.0/0 1 40 0 0 0 > 25 ip 0.0.0.0/0 3617690 3501375619 0 > 0 602 > 26 ip 0.0.0.0/0 12116 12039435 0 0 0 > 27 ip 0.0.0.0/0 524311 653399507 0 0 8 > 28 ip 0.0.0.0/0 3 417 0 0 0 > 29 ip 0.0.0.0/0 16 2034 0 0 0 > 30 ip 0.0.0.0/0 64 82661 3 4432 0 > 31 ip 0.0.0.0/0 946389 1175221367 0 0 66 > 32 ip 0.0.0.0/0 1 168 0 0 0 > 32 ip 0.0.0.0/0 28 41776 0 0 0 > 33 ip 0.0.0.0/0 6 6433 0 0 0 > 34 ip 0.0.0.0/0 1 536 0 0 0 > 35 ip 0.0.0.0/0 2021 2641048 0 0 0 > 36 ip 0.0.0.0/0 350 264039 0 0 0 > 37 ip 0.0.0.0/0 167578 137763107 0 0 0 > 38 ip 0.0.0.0/0 250404 128905757 0 0 0 > 39 ip 0.0.0.0/0 385139 287006012 0 0 0 > 40 ip 0.0.0.0/0 49 68696 0 0 0 > 41 ip 0.0.0.0/0 23 1813 0 0 0 > 42 ip 0.0.0.0/0 129 135256 0 0 0 > 43 ip 0.0.0.0/0 3232 2191027 0 0 0 > 44 ip 0.0.0.0/0 27935157 24307287646 0 > 0 18802 > 45 ip 0.0.0.0/0 2166 212635 0 0 0 > 46 ip 0.0.0.0/0 1127307 1392467620 0 > 0 3 > 47 ip 0.0.0.0/0 1216900 1258200836 0 > 0 0 > 48 ip 0.0.0.0/0 2 2984 1 1492 0 > 49 ip 0.0.0.0/0 1 112 0 0 0 > 50 ip 0.0.0.0/0 1409 326389 0 0 0 > 51 ip 0.0.0.0/0 46674 47291021 10 14920 0 > 52 ip 0.0.0.0/0 86667 66834983 0 0 0 > 53 ip 0.0.0.0/0 434998 302827189 0 0 0 > 54 ip 0.0.0.0/0 542 277669 0 0 0 > 55 ip 0.0.0.0/0 1088072 919495021 0 0 0 > 56 ip 0.0.0.0/0 64 81240 0 0 0 > 57 ip 0.0.0.0/0 41028 59193278 0 0 0 > 58 ip 0.0.0.0/0 1 210 0 0 0 > 59 ip 0.0.0.0/0 4 310 0 0 0 > 60 ip 0.0.0.0/0 2 2984 0 0 0 > 61 ip 0.0.0.0/0 42874 36616688 0 0 0 > 62 ip 0.0.0.0/0 4 498 0 0 0 > 63 ip 0.0.0.0/0 530137 717027403 0 0 0 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From rihad at mail.ru Mon Oct 5 17:23:57 2009 From: rihad at mail.ru (rihad) Date: Mon Oct 5 17:24:05 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACA26D4.2080102@elischer.org> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <20091005100446.GA60244@onelab2.iet.unipi.it> <4ACA26D4.2080102@elischer.org> Message-ID: <4ACA2BA6.40709@mail.ru> Julian Elischer wrote: > Luigi Rizzo wrote: > >>> Taildrop does not really help with this. GRED does much better. >> >> i think the first problem here is figure out _why_ we have >> the drops, as the original poster said that queues are configured >> with a very large amount of buffer (and i think there is a >> misconfiguration somewhere because the mbuf stats do not make >> sense) > > it all depends on the characteristics of the traffic > > you need different queue lengths if it is just a small number of high > speeed sessions (and mayne a large number of slow speed sessions), > or if it is a larger number of medium speed sessions. > > Is it possible to know what sessions are losing packets? > Yes, of course, by running ipfw pipe show ;-) There's one confusing thing, though: net.inet.ip.dummynet.io_pkt_drop isn't increasing while around 800-1000 packets per second are being dropped right now. And so "ipfw pipe show" Drp column wouldn't grow either. So it's either not dummynet dropping packets, or a bug (?). From julian at elischer.org Mon Oct 5 17:25:54 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Oct 5 17:26:02 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AC9E29B.6080908@mail.ru> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> Message-ID: <4ACA2C24.2060205@elischer.org> rihad wrote: > Luigi Rizzo wrote: >> On Mon, Oct 05, 2009 at 04:29:02PM +0500, rihad wrote: >>> Luigi Rizzo wrote: >> ... >>>> you keep omitting the important info i.e. whether individual >>>> pipes have drops, significant queue lenghts and so on. >>>> >>> Sorry. Almost everyone has 0 in the last Drp column, but some have >>> above zero. I'm not just sure how this can be helpful to anyone. >> >> because you were complaining about 'dummynet causing drops and >> waste of bandwidth'. >> Now, drops could be due to either >> 1) some saturation in the dummynet machine (memory shortage, cpu >> shortage, etc.) which cause unwanted drops; >> > I too think the box is hitting some other global limit and dropping > packets. If not, then how come that between 4a.m. and 10a.m. when the > traffic load is at 250-330 mbit/s there isn't a single drop? > >> 2) intentional drops introduced by dummynet because a flow exceeds >> its queue size. These drops are those shown in the 'Drop' >> column in 'ipfw pipe show' (they are cumulative, so you >> should do an 'ipfw pipe delete; ipfw pipe 5120 config ...' >> whenever you want to re-run the stats, or compute the >> differences between subsequent reads, to figure out what >> happens. >> >> If all drops you are seeing are of type 2, then there is nothing >> you can do to remove them: you set a bandwidth limit, the >> client is sending faster than it should, perhaps with UDP >> so even RED/GRED won't help you, and you see the drops >> once the queue starts to fill up. >> Examples below: the entries in bucket 4 and 44 >> > Then I guess I'm left with increasing slots and see how it goes. > Currently it's set to 10000 for each pipe. Thanks for yours and Eugene's > efforts, I appreciate it. > >> If you are seeing drops that are not listed in 'pipe show' >> then yun need to investigate where the packets are lost, >> again it could be on the output queue of the interface >> (due to the burstiness introduced by dummynet), or shortage >> of mbufs (but this did not seem to be the case from your >> previous stats) or something else. >> > This indeed is not a problem, proved by the fact that, like I said, > short-circuiting "ipfw allow ip from any to any" before dummynet pipe > rules instantly eliminates all drops, and bce0 and bce1 load evens out > (bce0 used for input, and bce1 for output). no it could be a problem because dummy net releases all the packets for a slot that are going ot be let for a tick out at once, instead of having them arrive spread out through the tick. also it does one pipe at a time which means that related packets arrive at once followed by packets from other sessions.. this may produce differences in some cases. > >> It's all up to you to run measurements, possibly >> without omitting potentially significant data >> (e.g. sysctl -a net.inet.ip) >> or making assumptions (e.g. you have configured >> 5000 slots per queue, but with only 50k mbufs in total >> there is no chance to guarantee 5000 slots to each >> queue -- all you will achieve is give a lot of slots >> to the greedy nodes, and very little to the other ones) >> > Well, I've been monitoring this stuff. It has never reached above 20000 > mbufs (111111 is the current limit). > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From julian at elischer.org Mon Oct 5 17:27:14 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Oct 5 17:27:20 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AC9E415.9040801@mail.ru> References: <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <20091005100446.GA60244@onelab2.iet.unipi.it> <20091005100532.GC73335@svzserv.kemerovo.su> <4AC9C88A.5050509@mail.ru> <20091005113037.GA77999@svzserv.kemerovo.su> <4AC9DD72.9060802@mail.ru> <20091005120057.GA79942@svzserv.kemerovo.su> <4AC9E415.9040801@mail.ru> Message-ID: <4ACA2C74.9030206@elischer.org> rihad wrote: > Eugene Grosbein wrote: >> On Mon, Oct 05, 2009 at 04:50:10PM +0500, rihad wrote: >> >>>>> Where has TCP slow-start gone? My router box isn't some application >>>>> proxy that starts downloading at full 100 mbit/s thus quickly >>>>> filling client's 1 mbit/s link. It's just a router. >>>> While there is no or little competition for bandwidth from the router >>>> to clients, TCP would work just fine. I suspect your shaping policy >>>> makes heavy competition between clients. In this case, TCP behaves >>>> not-so-well without help of router's good shaping algorythms >>>> and taildrop is not good one. >>>> >>> Nothing fancy (i.e. no competition). Only tons of per-user pipes >>> simulating the given throughput. >> >> You've mentioned previously: "The pipes are fine, each normally having >> 100-120 concurrent consumers (i.e. active users)." >> This IS competition between TCP flows inside each pipe. >> > Well, each user gets instantiated with a new copy of the pipe. Each such > user counts towards the limit imposed by hash_size*max_chain_len for > that pipe only. It would have been competition had I used dst-ip dst-ip > 0xffffff00 or similar and not dst-ip 0xffffffff, _then_ all 256 users > (determined by the mask) would compete for the pipe's bandwidth. So the > only competition is in the uplink at our main Cisco, I guess. yesssss, so try running your interfaces slower. :-) > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From julian at elischer.org Mon Oct 5 17:28:37 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Oct 5 17:28:44 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AC9EFDF.4080302@mail.ru> References: <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> Message-ID: <4ACA2CC6.70201@elischer.org> rihad wrote: > Luigi Rizzo wrote: >> On Mon, Oct 05, 2009 at 05:12:11PM +0500, rihad wrote: >>> Luigi Rizzo wrote: >>>> On Mon, Oct 05, 2009 at 04:29:02PM +0500, rihad wrote: >>>>> Luigi Rizzo wrote: >>>> ... >>>>>> you keep omitting the important info i.e. whether individual >>>>>> pipes have drops, significant queue lenghts and so on. >>>>>> >>>>> Sorry. Almost everyone has 0 in the last Drp column, but some have >>>>> above zero. I'm not just sure how this can be helpful to anyone. >>>> because you were complaining about 'dummynet causing drops and >>>> waste of bandwidth'. >>>> Now, drops could be due to either >>>> 1) some saturation in the dummynet machine (memory shortage, cpu >>>> shortage, etc.) which cause unwanted drops; >>>> >>> I too think the box is hitting some other global limit and dropping >>> packets. If not, then how come that between 4a.m. and 10a.m. when the >>> traffic load is at 250-330 mbit/s there isn't a single drop? >> >> there may be different reasons, e.g. the big offenders were >> idle when you saw no drops. You still do not have enough >> information on which packets are dropped and where, >> so you cannot prove your assumptions. >> >> Also, below: >> 1. increasing the queue size won't help at all. Those >> who overflow a queue of 1000 slots will also overflow >> a queue of 10k slots. >> > >> 2. your test with 'ipfw allow ip from any to any' does not >> prove that the interface queue is not saturating, because >> you also remove the burstiness that dummynet introduces, >> and so the queue is driven differently. >> > > There's one thing I noticed: > net.inet.ip.dummynet.io_pkt_drop doesn't grow! But still around 400 > packets dropped per second. > net.inet.ip.dummynet.tick_lost is always zero > net.inet.ip.dummynet.tick_diff: grows at about 50 per second. > net.inet.ip.dummynet.tick_adjustment: grows at about 5 per second. > > How do I investigate and fix this burstiness issue? higher Hz rate? > > > $ netstat -i > Name Mtu Network Address Ipkts Ierrs Opkts > Oerrs Coll > bce0 1500 00:1d:09:xx:xx:xx 24777049059 0 75426020 > 0 0 > bce0 1500 xx.xx.xx.xx/xx my.hostname 159293969 - 75282225 > - - > bce1 1500 00:1d:09:xx:xx:xx 724725 0 24514919344 > 0 0 > bce1 1500 192.168.94.0 local.hostname 656243 - 83024869 - - > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From rihad at mail.ru Mon Oct 5 17:33:44 2009 From: rihad at mail.ru (rihad) Date: Mon Oct 5 17:33:56 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACA2A52.4050704@elischer.org> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <4ACA2A52.4050704@elischer.org> Message-ID: <4ACA2DDB.50809@mail.ru> Julian Elischer wrote: > rihad wrote: >> Luigi Rizzo wrote: >>> On Mon, Oct 05, 2009 at 03:52:39PM +0500, rihad wrote: >>>> Eugene Grosbein wrote: >>>>> On Mon, Oct 05, 2009 at 02:28:58PM +0500, rihad wrote: >>>>> >>>>>> Still not sure why increasing queue size as high as I want doesn't >>>>>> completely eliminate drops. >>>>> The goal is to make sources of traffic to slow down, this is the only >>>>> way to descrease drops - any finite queue may be overhelmed with >>>>> traffic. >>>>> Taildrop does not really help with this. GRED does much better. >>>>> >>>> Alright, so I changed to gred by adding to each config command: >>>> ipfw ... gred 0.002/900/1000/0.1 queue 1000 >>>> and reconfigured. Still around 300-400 drops per second, which was >>>> typical at this load level before with taildrop anyway. There are >>>> around 3-5 mbit/s being wasted according to systat -ifstat. >>>> >>>> Should I now increase slots to 5-10-20k? >>>> Very strange. >>>> >>>> "ipfw pipe show" correctly shows that gred is at work. For example: >>>> 00512: 512.000 Kbit/s 0 ms 1000 sl. 79 queues (64 buckets) >>>> GRED w_q 0.001999 min_th 900 max_th 1000 max_p 0.099991 >>>> mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 >>>> ... >>> >>> you keep omitting the important info i.e. whether individual >>> pipes have drops, significant queue lenghts and so on. >>> >> Sorry. Almost everyone has 0 in the last Drp column, but some have >> above zero. I'm not just sure how this can be helpful to anyone. > > > This tells us there are just a few sessions with VERY LARGE WINDOWS > that are trying to push the link too fast. They are flooding the > firewall and geting all the drops. (unless the problem is that the > hash/mask is putting a lot of session on the same slot.) > > All masks are dst-ip 0xffffffff. I doubt very strongly that it's due to such offenders, because all the way from 4a.m. to 10a.m. at the load of 200-330 mbit/s there are zero drops. There are no doubt heavy downloaders leaving their PCs on in the night. The drops begin as soon as the load crosses 340-360 mbit/s or some such, and it only worsens as the load approaches 500-530 mbit/s. From julian at elischer.org Mon Oct 5 17:49:43 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Oct 5 17:49:50 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091005154236.GA95635@svzserv.kemerovo.su> References: <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <20091005140409.GB89194@svzserv.kemerovo.su> <4ACA02F7.6040409@mail.ru> <20091005145037.GA92519@svzserv.kemerovo.su> <4ACA0BA6.70706@mail.ru> <20091005154236.GA95635@svzserv.kemerovo.su> Message-ID: <4ACA31B9.5090406@elischer.org> Eugene Grosbein wrote: > On Mon, Oct 05, 2009 at 08:07:18PM +0500, rihad wrote: > >>> What is CPU load in when the load is maximum? >>> >> It has 2 quad-cores, so I'm not sure. Here's the output of top -S: > > There is a rumour about FreeBSD's shedulers... > That they are not so good for 8 cores and that you may get MORE speed > by disabling 4 cores if it's possible for your system. > Or even using uniprocessor kernel. > > Only rumour, though :-) > true for 6.x, less true for 7.x, and not true for 8.x > Eugene Grosbein > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From julian at elischer.org Mon Oct 5 17:56:42 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Oct 5 17:56:56 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACA2BA6.40709@mail.ru> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <20091005100446.GA60244@onelab2.iet.unipi.it> <4ACA26D4.2080102@elischer.org> <4ACA2BA6.40709@mail.ru> Message-ID: <4ACA335C.2060806@elischer.org> rihad wrote: > Julian Elischer wrote: >> Luigi Rizzo wrote: >> >>>> Taildrop does not really help with this. GRED does much better. >>> >>> i think the first problem here is figure out _why_ we have >>> the drops, as the original poster said that queues are configured >>> with a very large amount of buffer (and i think there is a >>> misconfiguration somewhere because the mbuf stats do not make >>> sense) >> >> it all depends on the characteristics of the traffic >> >> you need different queue lengths if it is just a small number of high >> speeed sessions (and mayne a large number of slow speed sessions), >> or if it is a larger number of medium speed sessions. >> >> Is it possible to know what sessions are losing packets? >> > Yes, of course, by running ipfw pipe show ;-) > There's one confusing thing, though: net.inet.ip.dummynet.io_pkt_drop > isn't increasing while around 800-1000 packets per second are being > dropped right now. And so "ipfw pipe show" Drp column wouldn't grow > either. So it's either not dummynet dropping packets, or a bug (?). I suspect your interface queues. From rihad at mail.ru Mon Oct 5 17:56:47 2009 From: rihad at mail.ru (rihad) Date: Mon Oct 5 17:56:57 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACA2CC6.70201@elischer.org> References: <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> Message-ID: <4ACA3359.9040604@mail.ru> Julian Elischer wrote: >> How do I investigate and fix this burstiness issue? > > higher Hz rate? > Hmm, mine is 1000. I'll try bumping it up to 2000 (via /boot/loader.conf) but since a reboot is required I think it'll have to wait for a while. From rihad at mail.ru Mon Oct 5 18:03:36 2009 From: rihad at mail.ru (rihad) Date: Mon Oct 5 18:03:42 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACA335C.2060806@elischer.org> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <20091005100446.GA60244@onelab2.iet.unipi.it> <4ACA26D4.2080102@elischer.org> <4ACA2BA6.40709@mail.ru> <4ACA335C.2060806@elischer.org> Message-ID: <4ACA34F3.60901@mail.ru> Julian Elischer wrote: > rihad wrote: >> Julian Elischer wrote: >>> Luigi Rizzo wrote: >>> >>> Is it possible to know what sessions are losing packets? >>> >> Yes, of course, by running ipfw pipe show ;-) >> There's one confusing thing, though: net.inet.ip.dummynet.io_pkt_drop >> isn't increasing while around 800-1000 packets per second are being >> dropped right now. And so "ipfw pipe show" Drp column wouldn't grow >> either. So it's either not dummynet dropping packets, or a bug (?). > > > I suspect your interface queues. > You mean in hardware? Any way to tweak those? From julian at elischer.org Mon Oct 5 18:54:49 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Oct 5 18:54:55 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACA34F3.60901@mail.ru> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <20091005100446.GA60244@onelab2.iet.unipi.it> <4ACA26D4.2080102@elischer.org> <4ACA2BA6.40709@mail.ru> <4ACA335C.2060806@elischer.org> <4ACA34F3.60901@mail.ru> Message-ID: <4ACA40FA.7010207@elischer.org> rihad wrote: > Julian Elischer wrote: >> rihad wrote: >>> Julian Elischer wrote: >>>> Luigi Rizzo wrote: >>>> >>>> Is it possible to know what sessions are losing packets? >>>> >>> Yes, of course, by running ipfw pipe show ;-) >>> There's one confusing thing, though: net.inet.ip.dummynet.io_pkt_drop >>> isn't increasing while around 800-1000 packets per second are being >>> dropped right now. And so "ipfw pipe show" Drp column wouldn't grow >>> either. So it's either not dummynet dropping packets, or a bug (?). >> >> >> I suspect your interface queues. >> > > You mean in hardware? Any way to tweak those? no, there is (usually) a software queue before the hardware queue. look at /sys/net/if_ethersubr.c From eugen at kuzbass.ru Tue Oct 6 04:21:59 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Tue Oct 6 04:22:06 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACA02F7.6040409@mail.ru> References: <20091005095600.GA73335@svzserv.kemerovo.su> <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <20091005140409.GB89194@svzserv.kemerovo.su> <4ACA02F7.6040409@mail.ru> Message-ID: <20091006042153.GA5857@svzserv.kemerovo.su> On Mon, Oct 05, 2009 at 07:30:15PM +0500, rihad wrote: > >>How do I investigate and fix this burstiness issue? > > > >Please also show: > > > >sysctl net.isr > >sysctl net.inet.ip.intr_queue_maxlen > > net.isr.swi_count: 65461359 > net.isr.drop: 0 > net.isr.queued: 32843752 > net.isr.deferred: 0 > net.isr.directed: -723075002 > net.isr.count: -723074001 > net.isr.direct: 1 > > net.inet.ip.intr_queue_maxlen: 50 Try to increase net.inet.ip.intr_queue_maxlen uptio 4096. Eugene From eugen at kuzbass.ru Tue Oct 6 04:23:43 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Tue Oct 6 04:23:49 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACA31B9.5090406@elischer.org> References: <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <20091005140409.GB89194@svzserv.kemerovo.su> <4ACA02F7.6040409@mail.ru> <20091005145037.GA92519@svzserv.kemerovo.su> <4ACA0BA6.70706@mail.ru> <20091005154236.GA95635@svzserv.kemerovo.su> <4ACA31B9.5090406@elischer.org> Message-ID: <20091006042335.GB5857@svzserv.kemerovo.su> On Mon, Oct 05, 2009 at 10:49:45AM -0700, Julian Elischer wrote: > >There is a rumour about FreeBSD's shedulers... > >That they are not so good for 8 cores and that you may get MORE speed > >by disabling 4 cores if it's possible for your system. > >Or even using uniprocessor kernel. > >Only rumour, though :-) > true for 6.x, less true for 7.x, and not true for 8.x That's great. For both of ULE and BSD? Eugene From rihad at mail.ru Tue Oct 6 04:38:41 2009 From: rihad at mail.ru (rihad) Date: Tue Oct 6 04:38:48 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091006042153.GA5857@svzserv.kemerovo.su> References: <20091005095600.GA73335@svzserv.kemerovo.su> <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <20091005140409.GB89194@svzserv.kemerovo.su> <4ACA02F7.6040409@mail.ru> <20091006042153.GA5857@svzserv.kemerovo.su> Message-ID: <4ACAC9CE.7080900@mail.ru> Eugene Grosbein wrote: > On Mon, Oct 05, 2009 at 07:30:15PM +0500, rihad wrote: > >>>> How do I investigate and fix this burstiness issue? >>> Please also show: >>> >>> sysctl net.isr >>> sysctl net.inet.ip.intr_queue_maxlen >> net.isr.swi_count: 65461359 >> net.isr.drop: 0 >> net.isr.queued: 32843752 >> net.isr.deferred: 0 >> net.isr.directed: -723075002 >> net.isr.count: -723074001 >> net.isr.direct: 1 >> >> net.inet.ip.intr_queue_maxlen: 50 > > Try to increase net.inet.ip.intr_queue_maxlen uptio 4096. > You sure? Packets are never dropped once I add "allow ip from any to any" before pipes, effectively turning dummynet off. Yet I've doubled it for starters (50->100) let's see if it works in an hour or so, when it's 10:30 here. From rihad at mail.ru Tue Oct 6 05:21:20 2009 From: rihad at mail.ru (rihad) Date: Tue Oct 6 05:21:27 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACAC9CE.7080900@mail.ru> References: <20091005095600.GA73335@svzserv.kemerovo.su> <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <20091005140409.GB89194@svzserv.kemerovo.su> <4ACA02F7.6040409@mail.ru> <20091006042153.GA5857@svzserv.kemerovo.su> <4ACAC9CE.7080900@mail.ru> Message-ID: <4ACAD3CD.4000908@mail.ru> > Eugene Grosbein wrote: >> Try to increase net.inet.ip.intr_queue_maxlen uptio 4096. >> > You sure? Packets are never dropped once I add "allow ip from any to > any" before pipes, effectively turning dummynet off. Yet I've doubled it > for starters (50->100) let's see if it works in an hour or so, when it's > 10:30 here. > Besides, net.inet.ip.intr_queue_maxlen: Maximum size of the IP input queue but the drops have been occurring on the _output_. I'll see in about 10 minutes if it's true or not. I've also set up kern.hz=2000 in loader.conf the effects of which will be seen in an hour or so, when I'm permitted to reboot the box. From rihad at mail.ru Tue Oct 6 06:38:55 2009 From: rihad at mail.ru (rihad) Date: Tue Oct 6 06:39:03 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091006042153.GA5857@svzserv.kemerovo.su> References: <20091005095600.GA73335@svzserv.kemerovo.su> <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <20091005140409.GB89194@svzserv.kemerovo.su> <4ACA02F7.6040409@mail.ru> <20091006042153.GA5857@svzserv.kemerovo.su> Message-ID: <4ACAE5FC.7040605@mail.ru> Eugene Grosbein wrote: > On Mon, Oct 05, 2009 at 07:30:15PM +0500, rihad wrote: > >>>> How do I investigate and fix this burstiness issue? >>> Please also show: >>> >>> sysctl net.isr >>> sysctl net.inet.ip.intr_queue_maxlen >> net.isr.swi_count: 65461359 >> net.isr.drop: 0 >> net.isr.queued: 32843752 >> net.isr.deferred: 0 >> net.isr.directed: -723075002 >> net.isr.count: -723074001 >> net.isr.direct: 1 >> >> net.inet.ip.intr_queue_maxlen: 50 > > Try to increase net.inet.ip.intr_queue_maxlen uptio 4096. > Apparently increasing the input queue had no effect on the output drops. Besides, net.inet.ip.intr_queue_drops has only reached 70 for 6 days of uptime. I'll soon be rebooting to change HZ 1000 -> 2000, and we'll see how that goes. There must be some global limit, not nmbclusters, not per-user output queues, not the interface input queue, but something else that triggers at around 360-370 mbit/s... From rihad at mail.ru Tue Oct 6 08:26:23 2009 From: rihad at mail.ru (rihad) Date: Tue Oct 6 08:26:31 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACA2CC6.70201@elischer.org> References: <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> Message-ID: <4ACAFF2A.1000206@mail.ru> Julian Elischer wrote: > rihad wrote: >> Luigi Rizzo wrote: >>> 2. your test with 'ipfw allow ip from any to any' does not >>> prove that the interface queue is not saturating, because >>> you also remove the burstiness that dummynet introduces, >>> and so the queue is driven differently. >>> >> >> How do I investigate and fix this burstiness issue? > > higher Hz rate? > Rebooted with HZ=2000 10 minutes ago. Due to application design the ipfw table (pipe tablearg) was flushed, so there are now 350 (and increasing at a rate 1 per 1-2 seconds as I type this) or so users in the table, and not 4k as normally would be. The box is servicing 450+ mbit/s without a single drop. I want to monitor how things change once the number of users in ipfw tables gradually increases up to several thousands. From gaurav0287 at gmail.com Tue Oct 6 09:20:03 2009 From: gaurav0287 at gmail.com (Gaurav Goel) Date: Tue Oct 6 09:20:13 2009 Subject: kern/138652: TCP window scaling value calculated incorrectly? Message-ID: <200910060920.n969K3K9071480@freefall.freebsd.org> The following reply was made to PR kern/138652; it has been noted by GNATS. From: Gaurav Goel To: bug-followup@freebsd.org Cc: Subject: Re: kern/138652: TCP window scaling value calculated incorrectly? Date: Tue, 6 Oct 2009 14:47:52 +0530 --000feaf371bd7882aa047540b470 Content-Type: text/plain; charset=UTF-8 Hi, May I know if someone is working on the bug. I have provided the solution too, but didn't get any response. Thanks, Gaurav Goel On Thu, Sep 10, 2009 at 7:00 PM, Gaurav Goel wrote: > Dear Gavin, > > Please find the fix for the problem: > > *Replace* > * while (tp->request_r_scale < TCP_MAX_WINSHIFT && > (TCP_MAXWIN << tp->request_r_scale) < sb_max) > tp->request_r_scale++;* > > *With* > *unsigned int new_TCP_MAXWIN = TCP_MAXWIN; > while (tp->request_r_scale < TCP_MAX_WINSHIFT) > { > if(new_TCP_MAXWIN < sb_max) > tp->request_r_scale++; > else > break;** > ** new_TCP_MAXWIN <<=1;** > ** new_TCP_MAXWIN |=1;** > **}* > > Please inform me if I am right/wrong. > > Thanks, > Gaurav Goel > > > On Wed, Sep 9, 2009 at 7:59 PM, wrote: > >> Old Synopsis: TCP window scaling value >> New Synopsis: TCP window scaling value calculated incorrectly? >> >> State-Changed-From-To: feedback->open >> State-Changed-By: gavin >> State-Changed-When: Wed Sep 9 14:24:24 UTC 2009 >> State-Changed-Why: >> Over to maintainer(s) for investigation >> >> >> Responsible-Changed-From-To: gavin->freebsd-net >> Responsible-Changed-By: gavin >> Responsible-Changed-When: Wed Sep 9 14:24:24 UTC 2009 >> Responsible-Changed-Why: >> Feedback was received, thanks! >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=138652 >> > > > > -- > Gaurav Goel > -- Gaurav Goel --000feaf371bd7882aa047540b470 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,

May I know if someone is working on the bug. I have provided the= solution too, but didn't get any response.

Thanks,
Gaurav Go= el

On Thu, Sep 10, 2009 at 7:00 PM, Gaura= v Goel <gaurav= 0287@gmail.com> wrote:
Dear Gavin,
Please find the fix for the problem:

Replace
<= span style=3D"color: rgb(153, 0, 0); background-color: rgb(255, 255, 255);"= >=C2=A0=C2=A0=C2=A0 while (tp->request_r_scale < TCP_MAX_WINSHIFT &am= p;&
unsigne= d int new_TCP_MAXWIN =3D TCP_MAXWIN;
while (tp->request_r_scale &= lt; TCP_MAX_WINSHIFT)
{
=C2=A0=C2=A0=C2=A0 if(new_TCP_MAXWIN < sb_max)=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 tp->request_r_scale++;
=C2=A0=C2=A0=C2=A0 else
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;
=C2=A0=C2=A0=C2=A0 new_TCP_MAXWIN <<=3D1;=
=C2=A0=C2=A0=C2=A0 new_TCP_MAXWIN |=3D1;
}

Please in= form me if I am right/wrong.

Thanks,
Gaurav Goel
<= div class=3D"h5">

On Wed, Sep 9, 2009 at = 7:59 PM, <gavin@freebsd.org> wrote:
Old Synopsis: TCP= window scaling value
New Synopsis: TCP window scaling value calculated incorrectly?

State-Changed-From-To: feedback->open
State-Changed-By: gavin
State-Changed-When: Wed Sep 9 14:24:24 UTC 2009
State-Changed-Why:
Over to maintainer(s) for investigation


Responsible-Changed-From-To: gavin->freebsd-net
Responsible-Changed-By: gavin
Responsible-Changed-When: Wed Sep 9 14:24:24 UTC 2009
Responsible-Changed-Why:
Feedback was received, thanks!

http://www.freebsd.org/cgi/query-pr.cgi?pr=3D138652



--
Gaurav Goel



--
Gaurav Goel
--000feaf371bd7882aa047540b470-- From rihad at mail.ru Tue Oct 6 09:21:43 2009 From: rihad at mail.ru (rihad) Date: Tue Oct 6 09:21:50 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACAFF2A.1000206@mail.ru> References: <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> Message-ID: <4ACB0C22.4000008@mail.ru> rihad wrote: > Julian Elischer wrote: >> rihad wrote: >>> Luigi Rizzo wrote: >>>> 2. your test with 'ipfw allow ip from any to any' does not >>>> prove that the interface queue is not saturating, because >>>> you also remove the burstiness that dummynet introduces, >>>> and so the queue is driven differently. >>>> >>> >>> How do I investigate and fix this burstiness issue? >> >> higher Hz rate? >> > > Rebooted with HZ=2000 10 minutes ago. Due to application design the ipfw > table (pipe tablearg) was flushed, so there are now 350 (and increasing > at a rate 1 per 1-2 seconds as I type this) or so users in the table, > and not 4k as normally would be. The box is servicing 450+ mbit/s > without a single drop. I want to monitor how things change once the > number of users in ipfw tables gradually increases up to several thousands. > It starts dropping packets at around 2000 online users (ipfw table load). I've set up a shell script to monitor this: # while :; do ipfw table 0 list | wc -l; netstat -s 2>/dev/null |fgrep -w 'output packets dropped'; sleep 10; done ... # all zeroes above this 1999 0 output packets dropped due to no bufs, etc. 2001 0 output packets dropped due to no bufs, etc. 2008 0 output packets dropped due to no bufs, etc. 2017 0 output packets dropped due to no bufs, etc. 2027 156 output packets dropped due to no bufs, etc. 2037 156 output packets dropped due to no bufs, etc. 2045 156 output packets dropped due to no bufs, etc. 2372 202 output packets dropped due to no bufs, etc. 2377 207 output packets dropped due to no bufs, etc. 2391 338 output packets dropped due to no bufs, etc. 2402 394 output packets dropped due to no bufs, etc. 2415 531 output packets dropped due to no bufs, etc. 2421 725 output packets dropped due to no bufs, etc. Is there some limit on the number of IP addresses in an ipfw table? From rizzo at iet.unipi.it Tue Oct 6 09:27:28 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Tue Oct 6 09:27:35 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACB0C22.4000008@mail.ru> References: <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> Message-ID: <20091006093408.GA86830@onelab2.iet.unipi.it> On Tue, Oct 06, 2009 at 02:21:38PM +0500, rihad wrote: > rihad wrote: > >Julian Elischer wrote: > >>rihad wrote: > >>>Luigi Rizzo wrote: > >>>>2. your test with 'ipfw allow ip from any to any' does not > >>>> prove that the interface queue is not saturating, because > >>>> you also remove the burstiness that dummynet introduces, > >>>> and so the queue is driven differently. > >>>> > >>> > >>>How do I investigate and fix this burstiness issue? > >> > >>higher Hz rate? > >> > > > >Rebooted with HZ=2000 10 minutes ago. Due to application design the ipfw > > table (pipe tablearg) was flushed, so there are now 350 (and increasing > >at a rate 1 per 1-2 seconds as I type this) or so users in the table, > >and not 4k as normally would be. The box is servicing 450+ mbit/s > >without a single drop. I want to monitor how things change once the > >number of users in ipfw tables gradually increases up to several thousands. > > > > It starts dropping packets at around 2000 online users (ipfw table > load). I've set up a shell script to monitor this: once again: you should check which pipes are dropping packets and whether the number of drops indicated in the pipes matches the counts indicated by netstat. cheers luigi > # while :; do ipfw table 0 list | wc -l; netstat -s 2>/dev/null |fgrep > -w 'output packets dropped'; sleep 10; done > > ... # all zeroes above this > 1999 > 0 output packets dropped due to no bufs, etc. > 2001 > 0 output packets dropped due to no bufs, etc. > 2008 > 0 output packets dropped due to no bufs, etc. > 2017 > 0 output packets dropped due to no bufs, etc. > 2027 > 156 output packets dropped due to no bufs, etc. > 2037 > 156 output packets dropped due to no bufs, etc. > 2045 > 156 output packets dropped due to no bufs, etc. > 2372 > 202 output packets dropped due to no bufs, etc. > 2377 > 207 output packets dropped due to no bufs, etc. > 2391 > 338 output packets dropped due to no bufs, etc. > 2402 > 394 output packets dropped due to no bufs, etc. > 2415 > 531 output packets dropped due to no bufs, etc. > 2421 > 725 output packets dropped due to no bufs, etc. > > > Is there some limit on the number of IP addresses in an ipfw table? > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From rihad at mail.ru Tue Oct 6 09:34:37 2009 From: rihad at mail.ru (rihad) Date: Tue Oct 6 09:34:45 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091006093408.GA86830@onelab2.iet.unipi.it> References: <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006093408.GA86830@onelab2.iet.unipi.it> Message-ID: <4ACB0F28.3000906@mail.ru> Luigi Rizzo wrote: > On Tue, Oct 06, 2009 at 02:21:38PM +0500, rihad wrote: >> rihad wrote: >>> Julian Elischer wrote: >>>> rihad wrote: >>>>> Luigi Rizzo wrote: >>>>>> 2. your test with 'ipfw allow ip from any to any' does not >>>>>> prove that the interface queue is not saturating, because >>>>>> you also remove the burstiness that dummynet introduces, >>>>>> and so the queue is driven differently. >>>>>> >>>>> How do I investigate and fix this burstiness issue? >>>> higher Hz rate? >>>> >>> Rebooted with HZ=2000 10 minutes ago. Due to application design the ipfw >>> table (pipe tablearg) was flushed, so there are now 350 (and increasing >>> at a rate 1 per 1-2 seconds as I type this) or so users in the table, >>> and not 4k as normally would be. The box is servicing 450+ mbit/s >>> without a single drop. I want to monitor how things change once the >>> number of users in ipfw tables gradually increases up to several thousands. >>> >> It starts dropping packets at around 2000 online users (ipfw table >> load). I've set up a shell script to monitor this: > > once again: > you should check which pipes are dropping packets and whether > the number of drops indicated in the pipes matches the counts > indicated by netstat. > It's impossible to do so accurately, since users come and go any moment, and their pipes expire, and it's plain useless. As to the accordance of packet drop rate with net.inet.ip.dummynet.io_pkt_drop, they vary wildly: 8664 output packets dropped due to no bufs, etc. net.inet.ip.dummynet.io_pkt_drop: 111 since boottime! From eugen at kuzbass.ru Tue Oct 6 10:07:36 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Tue Oct 6 10:07:43 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACB0C22.4000008@mail.ru> References: <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> Message-ID: <20091006100726.GA26426@svzserv.kemerovo.su> On Tue, Oct 06, 2009 at 02:21:38PM +0500, rihad wrote: > Is there some limit on the number of IP addresses in an ipfw table? No, generally handles much more. Please show your ipfw rule(s) containing 'tablearg'. Eugene From rizzo at iet.unipi.it Tue Oct 6 10:11:07 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Tue Oct 6 10:11:13 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACB0F28.3000906@mail.ru> References: <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006093408.GA86830@onelab2.iet.unipi.it> <4ACB0F28.3000906@mail.ru> Message-ID: <20091006101747.GA87655@onelab2.iet.unipi.it> On Tue, Oct 06, 2009 at 02:34:32PM +0500, rihad wrote: > Luigi Rizzo wrote: > >On Tue, Oct 06, 2009 at 02:21:38PM +0500, rihad wrote: > >>rihad wrote: > >>>Julian Elischer wrote: > >>>>rihad wrote: > >>>>>Luigi Rizzo wrote: > >>>>>>2. your test with 'ipfw allow ip from any to any' does not > >>>>>> prove that the interface queue is not saturating, because > >>>>>> you also remove the burstiness that dummynet introduces, > >>>>>> and so the queue is driven differently. > >>>>>> > >>>>>How do I investigate and fix this burstiness issue? > >>>>higher Hz rate? > >>>> > >>>Rebooted with HZ=2000 10 minutes ago. Due to application design the ipfw > >>>table (pipe tablearg) was flushed, so there are now 350 (and increasing > >>>at a rate 1 per 1-2 seconds as I type this) or so users in the table, > >>>and not 4k as normally would be. The box is servicing 450+ mbit/s > >>>without a single drop. I want to monitor how things change once the > >>>number of users in ipfw tables gradually increases up to several > >>>thousands. > >>> > >>It starts dropping packets at around 2000 online users (ipfw table > >>load). I've set up a shell script to monitor this: > > > >once again: > >you should check which pipes are dropping packets and whether > >the number of drops indicated in the pipes matches the counts > >indicated by netstat. > > > It's impossible to do so accurately, since users come and go any moment, > and their pipes expire, and it's plain useless. As to the accordance of > packet drop rate with net.inet.ip.dummynet.io_pkt_drop, they vary wildly: > > 8664 output packets dropped due to no bufs, etc. > net.inet.ip.dummynet.io_pkt_drop: 111 io_pkt_drop only reports packets dropped to errors (missing pipes, randomly forced packet drops which you don't use, no buffers and so on). The packets intentionally dropped in dummynet because queues are full are listed by 'ipfw pipe show'. Even if pipes expire, there is a difference between having partial information and completely ignoring what is available and claiming "it's plain useless". BTW at least while you try to debug the problem you can temporarily disable the pipe expire with 'sysctl net.inet.ip.dummynet.expire=0' and also you could poll the stats more frequently (say every 1-2-5 sec) to get a better idea of what happens. The one time you sent the 'pipe show' info there were clearly a few pipes with thousand packet drops -- as i said those are unavoidable and correspond to clients that systematically exceed their share (500k/1m as you set) e.g. because they are flooding the net with TCP SYN or UDP requests. This may be due to viruses, aggressive p2p, and so on. A single client can easily generate the extra 2000 packets per seconds that you are seeing. It's up to you to open your eyes looking for evidence, or close them and randomly blame one or another piece of the system. cheers luigi > since boottime! From rihad at mail.ru Tue Oct 6 13:15:07 2009 From: rihad at mail.ru (rihad) Date: Tue Oct 6 13:15:14 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091006100726.GA26426@svzserv.kemerovo.su> References: <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> Message-ID: <4ACB42D2.2070909@mail.ru> Eugene Grosbein wrote: > On Tue, Oct 06, 2009 at 02:21:38PM +0500, rihad wrote: > >> Is there some limit on the number of IP addresses in an ipfw table? > > No, generally handles much more. Please show your ipfw rule(s) > containing 'tablearg'. > 01031 x x allow ip from any to any 01040 x x skipto 1100 ip from table(127) to any out recv bce0 xmit bce1 01060 x x pipe tablearg ip from any to table(0) out recv bce0 xmit bce1 01070 x x allow ip from any to table(0) out recv bce0 xmit bce1 01100 x x pipe tablearg ip from any to table(2) out 65535 x x allow ip from any to any table(127) contains country-wide ISPs' netblocks (under 100 entries). table(0) and table(2) contain same user IP addresses, but different pipe IDs - normally around 3-4k entries each. Now please pay special attention to rule 1031. I've added it to bypass dummynet and stop packets from being dropped for now. Normally the rule isn't there. As I found out today after rebooting, drops only start occurring when the number of entries in table(0) exceeds 2000 or so (please see my previous email). Maybe it's a coincidence - I don't know. Global traffic load doesn't matter - it was approximately the same before and after the drops (around 450 mbit/s). From rihad at mail.ru Tue Oct 6 13:33:26 2009 From: rihad at mail.ru (rihad) Date: Tue Oct 6 13:33:33 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091006101747.GA87655@onelab2.iet.unipi.it> References: <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006093408.GA86830@onelab2.iet.unipi.it> <4ACB0F28.3000906@mail.ru> <20091006101747.GA87655@onelab2.iet.unipi.it> Message-ID: <4ACB4720.40004@mail.ru> Luigi Rizzo wrote: > On Tue, Oct 06, 2009 at 02:34:32PM +0500, rihad wrote: >> Luigi Rizzo wrote: >> 8664 output packets dropped due to no bufs, etc. >> net.inet.ip.dummynet.io_pkt_drop: 111 > > io_pkt_drop only reports packets dropped to errors (missing pipes, > randomly forced packet drops which you don't use, no buffers and so on). > > The packets intentionally dropped in dummynet because queues are full > are listed by 'ipfw pipe show'. > > Even if pipes expire, there is a difference between having partial > information and completely ignoring what is available and claiming > "it's plain useless". Ok, without looking I can say: there _are_ always some users overrunning their queues that have non-zero Drp column in ipfw pipe show. But they are also there downloading like crazy when the number of online users is below 2000 or so, so how come that they're overrunning their share without getting reflected in the global netstat -s drop counter? There are 0 drops! netstat -s only starts growing when the number of online users exceeds 2000. > > BTW at least while you try to debug the problem you can temporarily > disable the pipe expire with 'sysctl net.inet.ip.dummynet.expire=0' > and also you could poll the stats more frequently (say every 1-2-5 sec) > to get a better idea of what happens. > I've tried expire=0 for a while, too. No difference whatsoever. > The one time you sent the 'pipe show' info there were clearly > a few pipes with thousand packet drops -- as i said those are > unavoidable and correspond to clients that systematically > exceed their share (500k/1m as you set) e.g. because they are flooding > the net with TCP SYN or UDP requests. This may be due to viruses, > aggressive p2p, and so on. A single client can easily generate > the extra 2000 packets per seconds that you are seeing. > Only downloads (i.e. traffic arriving from the Net) crosses the PC at hand. What makes me think this is a global problem, is that the drops _never_ happen when the number of online users in IPFW tables is below 2000 or so, no matter how high global traffic load is. Please see my previous email with ipfw rules. From eugen at kuzbass.ru Tue Oct 6 14:22:06 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Tue Oct 6 14:22:12 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACB42D2.2070909@mail.ru> References: <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> Message-ID: <20091006142152.GA42350@svzserv.kemerovo.su> On Tue, Oct 06, 2009 at 06:14:58PM +0500, rihad wrote: > >No, generally handles much more. Please show your ipfw rule(s) > >containing 'tablearg'. > > 01031 x x allow ip from any to any > 01040 x x skipto 1100 ip from table(127) to any out > recv bce0 xmit bce1 > 01060 x x pipe tablearg ip from any to table(0) out > recv bce0 xmit bce1 > 01070 x x allow ip from any to table(0) out recv bce0 > xmit bce1 > 01100 x x pipe tablearg ip from any to table(2) out > 65535 x x allow ip from any to any > > table(127) contains country-wide ISPs' netblocks (under 100 entries). > table(0) and table(2) contain same user IP addresses, but different pipe > IDs - normally around 3-4k entries each. > > Now please pay special attention to rule 1031. I've added it to bypass > dummynet and stop packets from being dropped for now. Normally the rule > isn't there. > > As I found out today after rebooting, drops only start occurring when > the number of entries in table(0) exceeds 2000 or so (please see my > previous email). Maybe it's a coincidence - I don't know. Global traffic > load doesn't matter - it was approximately the same before and after the > drops (around 450 mbit/s). It's possible that pipe lookup by its number is inefficient and firewall keeps its lock for too much time while searching the pipe, just a guess. And packets start to drop, eh? Try setting net.isr.direct to 0 and make large net.inet.ip.intr_queue_maxlen. This way, one of your cores may run bce's thread, enqueue incoming packets and return to work immediately. The rest of processing may be performed by another kernel thread, hopefully using another core. Just to see if this changes anything. top -S should help here too. Eugene From rihad at mail.ru Tue Oct 6 15:28:43 2009 From: rihad at mail.ru (rihad) Date: Tue Oct 6 15:28:50 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091006142152.GA42350@svzserv.kemerovo.su> References: <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> Message-ID: <4ACB6223.1000709@mail.ru> Eugene Grosbein wrote: > On Tue, Oct 06, 2009 at 06:14:58PM +0500, rihad wrote: > >>> No, generally handles much more. Please show your ipfw rule(s) >>> containing 'tablearg'. >> 01031 x x allow ip from any to any >> 01040 x x skipto 1100 ip from table(127) to any out >> recv bce0 xmit bce1 >> 01060 x x pipe tablearg ip from any to table(0) out >> recv bce0 xmit bce1 >> 01070 x x allow ip from any to table(0) out recv bce0 >> xmit bce1 >> 01100 x x pipe tablearg ip from any to table(2) out >> 65535 x x allow ip from any to any >> >> table(127) contains country-wide ISPs' netblocks (under 100 entries). >> table(0) and table(2) contain same user IP addresses, but different pipe >> IDs - normally around 3-4k entries each. >> >> Now please pay special attention to rule 1031. I've added it to bypass >> dummynet and stop packets from being dropped for now. Normally the rule >> isn't there. >> >> As I found out today after rebooting, drops only start occurring when >> the number of entries in table(0) exceeds 2000 or so (please see my >> previous email). Maybe it's a coincidence - I don't know. Global traffic >> load doesn't matter - it was approximately the same before and after the >> drops (around 450 mbit/s). > > It's possible that pipe lookup by its number is inefficient > and firewall keeps its lock for too much time while searching the pipe, > just a guess. And packets start to drop, eh? > > Try setting net.isr.direct to 0 and make large net.inet.ip.intr_queue_maxlen. > This way, one of your cores may run bce's thread, enqueue incoming > packets and return to work immediately. The rest of processing may be > performed by another kernel thread, hopefully using another core. > Just to see if this changes anything. top -S should help here too. > Since this is a remote production box, I'm really scared of toggling such on/off flags I've never used before, particularly under heavy traffic loads, they're way too eager to lock up the whole system. I might try this tomorrow morning, though, first on another less critical box. p.s.: I've just tested toggling the flag on my virtual machine, it went fine. I don't think net.inet.ip.intr_queue_maxlen is relevant to this problem, as net.inet.ip.intr_queue_drops is normally zero or very close to it at all times. From stef at memberwebs.com Tue Oct 6 15:40:04 2009 From: stef at memberwebs.com (Stef Walter) Date: Tue Oct 6 15:40:10 2009 Subject: kern/137164: [netinet] [patch] assert panic imo_match_source() Message-ID: <200910061540.n96Fe3x0014870@freefall.freebsd.org> The following reply was made to PR kern/137164; it has been noted by GNATS. From: Stef Walter To: bug-followup@FreeBSD.org, jhanna@pangolin-systems.com, Bruce Simpson Cc: Subject: Re: kern/137164: [netinet] [patch] assert panic imo_match_source() Date: Tue, 06 Oct 2009 10:37:31 -0500 This is a multi-part message in MIME format. --------------090401010308070005060707 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks for working on getting all these multicast fixes in. Much appreciated! Just one more thing, previous to 7.x FreeBSD would return EADDRINUSE in the case of a double IP_ADD_MEMBERSHIP. Software like quagga uses this error code to detect this condition. As patched (and MFC'd in 7.x and 8.x) EINVAL is returned instead and this confuses such software. Currently the multicast code does not remove memberships from its internal structures when an interface goes down. It's hard for userland to reliably track the condition of a multicast membership that didn't go away due to an interface going down. So software like quagga uses EADDRINUSE to track the condition. Obviously, as you Bruce mentioned, an better solution needs to be found eventually WRT to 'dynamic' interfaces and the multicast code. But for now would the attached patch be acceptable? It would prevent regressions from FreeBSD 6.x. Thanks for considering, Stef --------------090401010308070005060707 Content-Type: text/x-diff; name="freebsd-mcast-eaddrinuse.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd-mcast-eaddrinuse.patch" --- sys/netinet/in_mcast.c.orig 2009-09-30 16:43:35.000000000 +0000 +++ sys/netinet/in_mcast.c 2009-09-30 17:04:59.000000000 +0000 @@ -2010,5 +2010,5 @@ * is atomic with allocation of a membership. */ - error = EINVAL; + error = EADDRINUSE; goto out_inp_locked; } --------------090401010308070005060707-- From eugen at kuzbass.ru Tue Oct 6 16:12:52 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Tue Oct 6 16:13:00 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACB6223.1000709@mail.ru> References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> Message-ID: <20091006161240.GA49940@svzserv.kemerovo.su> On Tue, Oct 06, 2009 at 08:28:35PM +0500, rihad wrote: > I don't think net.inet.ip.intr_queue_maxlen is relevant to this problem, > as net.inet.ip.intr_queue_drops is normally zero or very close to it at > all times. When net.isr.direct is 1, this queue is used very seldom. Would you change it to 0, it will be used extensively. Eugene From rihad at mail.ru Tue Oct 6 16:25:12 2009 From: rihad at mail.ru (rihad) Date: Tue Oct 6 16:25:19 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091006161240.GA49940@svzserv.kemerovo.su> References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> Message-ID: <4ACB6F60.7090407@mail.ru> Eugene Grosbein wrote: > On Tue, Oct 06, 2009 at 08:28:35PM +0500, rihad wrote: > >> I don't think net.inet.ip.intr_queue_maxlen is relevant to this problem, >> as net.inet.ip.intr_queue_drops is normally zero or very close to it at >> all times. > > When net.isr.direct is 1, this queue is used very seldom. > Would you change it to 0, it will be used extensively. > Ah, ok, thanks. I'll try that tomorrow. But still... > Try setting net.isr.direct to 0 and make large net.inet.ip.intr_queue_maxlen. > This way, one of your cores may run bce's thread, enqueue incoming > packets and return to work immediately. The rest of processing may be > performed by another kernel thread, hopefully using another core. > Just to see if this changes anything. top -S should help here too. It isn't the incoming bce0 losing packets, but rather the outgoing bce1, which is almost idle interrupt-wise: 29 root 1 -68 - 0K 16K CPU1 1 223:39 55.86% irq256: bce0 31 root 1 -68 - 0K 16K WAIT 2 19:27 4.10% irq257: bce1 From stas at FreeBSD.org Tue Oct 6 16:50:04 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Tue Oct 6 16:50:12 2009 Subject: kern/127587: [bge] [request] if_bge(4) doesn't support BCM576X family Message-ID: <200910061650.n96Go4lj074405@freefall.freebsd.org> The following reply was made to PR kern/127587; it has been noted by GNATS. From: Stanislav Sedov To: Stanislav Sedov Cc: Norikatsu Shigemura , matthieu , bug-followup@FreeBSD.org Subject: Re: kern/127587: [bge] [request] if_bge(4) doesn't support BCM576X family Date: Tue, 6 Oct 2009 20:46:13 +0400 --Signature=_Tue__6_Oct_2009_20_46_13_+0400_Jz_mOzdr9=3k/ma7 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 2 Oct 2009 15:28:55 +0400 Stanislav Sedov mentioned: > Hello, Norikatsu! >=20 > Can you check, please, if the patch matthieu proposed > works for you? >=20 Or, even better, can you, please, the following patch attached? It should add support for newest 576x models as well as for some other recent devices. Thanks! Index: sys/dev/bge/if_bgereg.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/dev/bge/if_bgereg.h (revision 197707) +++ sys/dev/bge/if_bgereg.h (working copy) @@ -218,6 +218,7 @@ #define BGE_PCI_UNDI_TX_BD_PRODIDX_LO 0xAC #define BGE_PCI_ISR_MBX_HI 0xB0 #define BGE_PCI_ISR_MBX_LO 0xB4 +#define BGE_PCI_PRODID_ASICREV 0xBC =20 /* PCI Misc. Host control register */ #define BGE_PCIMISCCTL_CLEAR_INTA 0x00000001 @@ -229,6 +230,7 @@ #define BGE_PCIMISCCTL_REG_WORDSWAP 0x00000040 #define BGE_PCIMISCCTL_INDIRECT_ACCESS 0x00000080 #define BGE_PCIMISCCTL_ASICREV 0xFFFF0000 +#define BGE_PCIMISCCTL_ASICREV_SHIFT 16 =20 #define BGE_HIF_SWAP_OPTIONS (BGE_PCIMISCCTL_ENDIAN_WORDSWAP) #if BYTE_ORDER =3D=3D LITTLE_ENDIAN @@ -245,66 +247,72 @@ (BGE_HIF_SWAP_OPTIONS|BGE_PCIMISCCTL_CLEAR_INTA| \ BGE_PCIMISCCTL_MASK_PCI_INTR|BGE_PCIMISCCTL_INDIRECT_ACCESS) =20 -#define BGE_CHIPID_TIGON_I 0x40000000 -#define BGE_CHIPID_TIGON_II 0x60000000 -#define BGE_CHIPID_BCM5700_A0 0x70000000 -#define BGE_CHIPID_BCM5700_A1 0x70010000 -#define BGE_CHIPID_BCM5700_B0 0x71000000 -#define BGE_CHIPID_BCM5700_B1 0x71010000 -#define BGE_CHIPID_BCM5700_B2 0x71020000 -#define BGE_CHIPID_BCM5700_B3 0x71030000 -#define BGE_CHIPID_BCM5700_ALTIMA 0x71040000 -#define BGE_CHIPID_BCM5700_C0 0x72000000 -#define BGE_CHIPID_BCM5701_A0 0x00000000 /* grrrr */ -#define BGE_CHIPID_BCM5701_B0 0x01000000 -#define BGE_CHIPID_BCM5701_B2 0x01020000 -#define BGE_CHIPID_BCM5701_B5 0x01050000 -#define BGE_CHIPID_BCM5703_A0 0x10000000 -#define BGE_CHIPID_BCM5703_A1 0x10010000 -#define BGE_CHIPID_BCM5703_A2 0x10020000 -#define BGE_CHIPID_BCM5703_A3 0x10030000 -#define BGE_CHIPID_BCM5703_B0 0x11000000 -#define BGE_CHIPID_BCM5704_A0 0x20000000 -#define BGE_CHIPID_BCM5704_A1 0x20010000 -#define BGE_CHIPID_BCM5704_A2 0x20020000 -#define BGE_CHIPID_BCM5704_A3 0x20030000 -#define BGE_CHIPID_BCM5704_B0 0x21000000 -#define BGE_CHIPID_BCM5705_A0 0x30000000 -#define BGE_CHIPID_BCM5705_A1 0x30010000 -#define BGE_CHIPID_BCM5705_A2 0x30020000 -#define BGE_CHIPID_BCM5705_A3 0x30030000 -#define BGE_CHIPID_BCM5750_A0 0x40000000 -#define BGE_CHIPID_BCM5750_A1 0x40010000 -#define BGE_CHIPID_BCM5750_A3 0x40030000 -#define BGE_CHIPID_BCM5750_B0 0x41000000 -#define BGE_CHIPID_BCM5750_B1 0x41010000 -#define BGE_CHIPID_BCM5750_C0 0x42000000 -#define BGE_CHIPID_BCM5750_C1 0x42010000 -#define BGE_CHIPID_BCM5750_C2 0x42020000 -#define BGE_CHIPID_BCM5714_A0 0x50000000 -#define BGE_CHIPID_BCM5752_A0 0x60000000 -#define BGE_CHIPID_BCM5752_A1 0x60010000 -#define BGE_CHIPID_BCM5752_A2 0x60020000 -#define BGE_CHIPID_BCM5714_B0 0x80000000 -#define BGE_CHIPID_BCM5714_B3 0x80030000 -#define BGE_CHIPID_BCM5715_A0 0x90000000 -#define BGE_CHIPID_BCM5715_A1 0x90010000 -#define BGE_CHIPID_BCM5715_A3 0x90030000 -#define BGE_CHIPID_BCM5755_A0 0xa0000000 -#define BGE_CHIPID_BCM5755_A1 0xa0010000 -#define BGE_CHIPID_BCM5755_A2 0xa0020000 -#define BGE_CHIPID_BCM5722_A0 0xa2000000 -#define BGE_CHIPID_BCM5754_A0 0xb0000000 -#define BGE_CHIPID_BCM5754_A1 0xb0010000 -#define BGE_CHIPID_BCM5754_A2 0xb0020000 -#define BGE_CHIPID_BCM5787_A0 0xb0000000 -#define BGE_CHIPID_BCM5787_A1 0xb0010000 -#define BGE_CHIPID_BCM5787_A2 0xb0020000 -#define BGE_CHIPID_BCM5906_A1 0xc0010000 -#define BGE_CHIPID_BCM5906_A2 0xc0020000 +#define BGE_CHIPID_TIGON_I 0x4000 +#define BGE_CHIPID_TIGON_II 0x6000 +#define BGE_CHIPID_BCM5700_A0 0x7000 +#define BGE_CHIPID_BCM5700_A1 0x7001 +#define BGE_CHIPID_BCM5700_B0 0x7100 +#define BGE_CHIPID_BCM5700_B1 0x7101 +#define BGE_CHIPID_BCM5700_B2 0x7102 +#define BGE_CHIPID_BCM5700_B3 0x7103 +#define BGE_CHIPID_BCM5700_ALTIMA 0x7104 +#define BGE_CHIPID_BCM5700_C0 0x7200 +#define BGE_CHIPID_BCM5701_A0 0x0000 /* grrrr */ +#define BGE_CHIPID_BCM5701_B0 0x0100 +#define BGE_CHIPID_BCM5701_B2 0x0102 +#define BGE_CHIPID_BCM5701_B5 0x0105 +#define BGE_CHIPID_BCM5703_A0 0x1000 +#define BGE_CHIPID_BCM5703_A1 0x1001 +#define BGE_CHIPID_BCM5703_A2 0x1002 +#define BGE_CHIPID_BCM5703_A3 0x1003 +#define BGE_CHIPID_BCM5703_B0 0x1100 +#define BGE_CHIPID_BCM5704_A0 0x2000 +#define BGE_CHIPID_BCM5704_A1 0x2001 +#define BGE_CHIPID_BCM5704_A2 0x2002 +#define BGE_CHIPID_BCM5704_A3 0x2003 +#define BGE_CHIPID_BCM5704_B0 0x2100 +#define BGE_CHIPID_BCM5705_A0 0x3000 +#define BGE_CHIPID_BCM5705_A1 0x3001 +#define BGE_CHIPID_BCM5705_A2 0x3002 +#define BGE_CHIPID_BCM5705_A3 0x3003 +#define BGE_CHIPID_BCM5750_A0 0x4000 +#define BGE_CHIPID_BCM5750_A1 0x4001 +#define BGE_CHIPID_BCM5750_A3 0x4000 +#define BGE_CHIPID_BCM5750_B0 0x4100 +#define BGE_CHIPID_BCM5750_B1 0x4101 +#define BGE_CHIPID_BCM5750_C0 0x4200 +#define BGE_CHIPID_BCM5750_C1 0x4201 +#define BGE_CHIPID_BCM5750_C2 0x4202 +#define BGE_CHIPID_BCM5714_A0 0x5000 +#define BGE_CHIPID_BCM5752_A0 0x6000 +#define BGE_CHIPID_BCM5752_A1 0x6001 +#define BGE_CHIPID_BCM5752_A2 0x6002 +#define BGE_CHIPID_BCM5714_B0 0x8000 +#define BGE_CHIPID_BCM5714_B3 0x8003 +#define BGE_CHIPID_BCM5715_A0 0x9000 +#define BGE_CHIPID_BCM5715_A1 0x9001 +#define BGE_CHIPID_BCM5715_A3 0x9003 +#define BGE_CHIPID_BCM5755_A0 0xa000 +#define BGE_CHIPID_BCM5755_A1 0xa001 +#define BGE_CHIPID_BCM5755_A2 0xa002 +#define BGE_CHIPID_BCM5722_A0 0xa200 +#define BGE_CHIPID_BCM5754_A0 0xb000 +#define BGE_CHIPID_BCM5754_A1 0xb001 +#define BGE_CHIPID_BCM5754_A2 0xb002 +#define BGE_CHIPID_BCM5761_A0 0x5761000 +#define BGE_CHIPID_BCM5761_A1 0x5761100 +#define BGE_CHIPID_BCM5784_A0 0x5784000 +#define BGE_CHIPID_BCM5784_A1 0x5784100 +#define BGE_CHIPID_BCM5787_A0 0xb000 +#define BGE_CHIPID_BCM5787_A1 0xb001 +#define BGE_CHIPID_BCM5787_A2 0xb002 +#define BGE_CHIPID_BCM5906_A1 0xc001 +#define BGE_CHIPID_BCM5906_A2 0xc002 +#define BGE_CHIPID_BCM57780_A0 0x57780000 +#define BGE_CHIPID_BCM57780_A1 0x57780001 =20 /* shorthand one */ -#define BGE_ASICREV(x) ((x) >> 28) +#define BGE_ASICREV(x) ((x) >> 12) #define BGE_ASICREV_BCM5701 0x00 #define BGE_ASICREV_BCM5703 0x01 #define BGE_ASICREV_BCM5704 0x02 @@ -319,9 +327,16 @@ #define BGE_ASICREV_BCM5754 0x0b #define BGE_ASICREV_BCM5787 0x0b #define BGE_ASICREV_BCM5906 0x0c +/* Should consult BGE_PCI_PRODID_ASICREV for ChipID */ +#define BGE_ASICREV_USE_PRODID_REG 0x0f +/* BGE_PCI_PRODID_ASICREV ASIC rev. identifiers. */ +#define BGE_ASICREV_BCM5761 0x5761 +#define BGE_ASICREV_BCM5784 0x5784 +#define BGE_ASICREV_BCM5785 0x5785 +#define BGE_ASICREV_BCM57780 0x57780 =20 /* chip revisions */ -#define BGE_CHIPREV(x) ((x) >> 24) +#define BGE_CHIPREV(x) ((x) >> 8) #define BGE_CHIPREV_5700_AX 0x70 #define BGE_CHIPREV_5700_BX 0x71 #define BGE_CHIPREV_5700_CX 0x72 @@ -331,6 +346,9 @@ #define BGE_CHIPREV_5704_BX 0x21 #define BGE_CHIPREV_5750_AX 0x40 #define BGE_CHIPREV_5750_BX 0x41 +/* BGE_PCI_PRODID_ASICREV chip rev. identifiers. */ +#define BGE_CHIPREV_5761_AX 0x57611 +#define BGE_CHIPREV_5784_AX 0x57841 =20 /* PCI DMA Read/Write Control register */ #define BGE_PCIDMARWCTL_MINDMA 0x000000FF @@ -861,6 +879,7 @@ #define BGE_SDCMODE_RESET 0x00000001 #define BGE_SDCMODE_ENABLE 0x00000002 #define BGE_SDCMODE_ATTN 0x00000004 +#define BGE_SDCMODE_CDELAY 0x00000010 =20 /* Send Data completion status register */ #define BGE_SDCSTAT_ATTN 0x00000004 @@ -1378,6 +1397,9 @@ #define BGE_RDMAMODE_PCI_FIFOOREAD_ATTN 0x00000100 #define BGE_RDMAMODE_LOCWRITE_TOOBIG 0x00000200 #define BGE_RDMAMODE_ALL_ATTNS 0x000003FC +#define BGE_RDMAMODE_BD_SBD_CRPT_ATTN 0x00000800 +#define BGE_RDMAMODE_MBUF_RBD_CRPT_ATTN 0x00001000 +#define BGE_RDMAMODE_MBUF_SBD_CRPT_ATTN 0x00002000 #define BGE_RDMAMODE_FIFO_SIZE_128 0x00020000 #define BGE_RDMAMODE_FIFO_LONG_BURST 0x00030000 =20 @@ -2101,6 +2123,7 @@ #define BCOM_DEVICEID_BCM5720 0x1658 #define BCOM_DEVICEID_BCM5721 0x1659 #define BCOM_DEVICEID_BCM5722 0x165A +#define BCOM_DEVICEID_BCM5723 0x165B #define BCOM_DEVICEID_BCM5750 0x1676 #define BCOM_DEVICEID_BCM5750M 0x167C #define BCOM_DEVICEID_BCM5751 0x1677 @@ -2115,13 +2138,22 @@ #define BCOM_DEVICEID_BCM5754M 0x1672 #define BCOM_DEVICEID_BCM5755 0x167B #define BCOM_DEVICEID_BCM5755M 0x1673 +#define BCOM_DEVICEID_BCM5761 0x1681 +#define BCOM_DEVICEID_BCM5761E 0x1680 +#define BCOM_DEVICEID_BCM5761S 0x1688 +#define BCOM_DEVICEID_BCM5761SE 0x1689 +#define BCOM_DEVICEID_BCM5764 0x1684 #define BCOM_DEVICEID_BCM5780 0x166A #define BCOM_DEVICEID_BCM5780S 0x166B #define BCOM_DEVICEID_BCM5781 0x16DD #define BCOM_DEVICEID_BCM5782 0x1696 +#define BCOM_DEVICEID_BCM5784 0x1698 +#define BCOM_DEVICEID_BCM5785F 0x16a0 +#define BCOM_DEVICEID_BCM5785G 0x1699 #define BCOM_DEVICEID_BCM5786 0x169A #define BCOM_DEVICEID_BCM5787 0x169B #define BCOM_DEVICEID_BCM5787M 0x1693 +#define BCOM_DEVICEID_BCM5787F 0x167f #define BCOM_DEVICEID_BCM5788 0x169C #define BCOM_DEVICEID_BCM5789 0x169D #define BCOM_DEVICEID_BCM5901 0x170D @@ -2129,6 +2161,10 @@ #define BCOM_DEVICEID_BCM5903M 0x16FF #define BCOM_DEVICEID_BCM5906 0x1712 #define BCOM_DEVICEID_BCM5906M 0x1713 +#define BCOM_DEVICEID_BCM57760 0x1690 +#define BCOM_DEVICEID_BCM57780 0x1692 +#define BCOM_DEVICEID_BCM57788 0x1691 +#define BCOM_DEVICEID_BCM57790 0x1694 =20 /* * Alteon AceNIC PCI vendor/device ID. @@ -2179,6 +2215,14 @@ #define SUN_VENDORID 0x108e =20 /* + * Fujitsu vendor/device IDs + */ +#define FJTSU_VENDORID 0x10cf +#define FJTSU_DEVICEID_PW008GE5 0x11a1 +#define FJTSU_DEVICEID_PW008GE4 0x11a2 +#define FJTSU_DEVICEID_PP250450 0x11cc /* PRIMEPOWER250/450 LAN */ + +/* * Offset of MAC address inside EEPROM. */ #define BGE_EE_MAC_OFFSET 0x7C @@ -2558,6 +2602,7 @@ #define BGE_FLAG_5705_PLUS 0x00002000 #define BGE_FLAG_5714_FAMILY 0x00004000 #define BGE_FLAG_575X_PLUS 0x00008000 +#define BGE_FLAG_5755_PLUS 0x00010000 #define BGE_FLAG_RX_ALIGNBUG 0x00100000 #define BGE_FLAG_NO_3LED 0x00200000 #define BGE_FLAG_ADC_BUG 0x00400000 @@ -2568,8 +2613,8 @@ #define BGE_FLAG_CRC_BUG 0x08000000 #define BGE_FLAG_5788 0x20000000 uint32_t bge_chipid; - uint8_t bge_asicrev; - uint8_t bge_chiprev; + uint32_t bge_asicrev; + uint32_t bge_chiprev; uint8_t bge_asf_mode; uint8_t bge_asf_count; struct bge_ring_data bge_ldata; /* rings */ Index: sys/dev/bge/if_bge.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/dev/bge/if_bge.c (revision 197707) +++ sys/dev/bge/if_bge.c (working copy) @@ -170,6 +170,7 @@ { BCOM_VENDORID, BCOM_DEVICEID_BCM5720 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5721 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5722 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5723 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5750 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5750M }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5751 }, @@ -184,12 +185,21 @@ { BCOM_VENDORID, BCOM_DEVICEID_BCM5754M }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5755 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5755M }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5761 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5761E }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5761S }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5761SE }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5764 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5780 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5780S }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5781 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5782 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5784 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5785F }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5785G }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5786 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5787 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5787F }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5787M }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5788 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5789 }, @@ -198,11 +208,19 @@ { BCOM_VENDORID, BCOM_DEVICEID_BCM5903M }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5906 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5906M }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM57760 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM57780 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM57788 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM57790 }, =20 { SK_VENDORID, SK_DEVICEID_ALTIMA }, =20 { TC_VENDORID, TC_DEVICEID_3C996 }, =20 + { FJTSU_VENDORID, FJTSU_DEVICEID_PW008GE4 }, + { FJTSU_VENDORID, FJTSU_DEVICEID_PW008GE5 }, + { FJTSU_VENDORID, FJTSU_DEVICEID_PP250450 }, + { 0, 0 } }; =20 @@ -216,6 +234,7 @@ { BCOM_VENDORID, "Broadcom" }, { SK_VENDORID, "SysKonnect" }, { TC_VENDORID, "3Com" }, + { FJTSU_VENDORID, "Fujitsu" }, =20 { 0, NULL } }; @@ -271,12 +290,18 @@ { BGE_CHIPID_BCM5755_A1, "BCM5755 A1" }, { BGE_CHIPID_BCM5755_A2, "BCM5755 A2" }, { BGE_CHIPID_BCM5722_A0, "BCM5722 A0" }, + { BGE_CHIPID_BCM5761_A0, "BCM5761 A0" }, + { BGE_CHIPID_BCM5761_A1, "BCM5761 A1" }, + { BGE_CHIPID_BCM5784_A0, "BCM5784 A0" }, + { BGE_CHIPID_BCM5784_A1, "BCM5784 A1" }, /* 5754 and 5787 share the same ASIC ID */ { BGE_CHIPID_BCM5787_A0, "BCM5754/5787 A0" },=20 { BGE_CHIPID_BCM5787_A1, "BCM5754/5787 A1" }, { BGE_CHIPID_BCM5787_A2, "BCM5754/5787 A2" }, { BGE_CHIPID_BCM5906_A1, "BCM5906 A1" }, { BGE_CHIPID_BCM5906_A2, "BCM5906 A2" }, + { BGE_CHIPID_BCM57780_A0, "BCM57780 A0" }, + { BGE_CHIPID_BCM57780_A1, "BCM57780 A1" }, =20 { 0, NULL } }; @@ -297,9 +322,13 @@ { BGE_ASICREV_BCM5780, "unknown BCM5780" }, { BGE_ASICREV_BCM5714, "unknown BCM5714" }, { BGE_ASICREV_BCM5755, "unknown BCM5755" }, + { BGE_ASICREV_BCM5761, "unknown BCM5761" }, + { BGE_ASICREV_BCM5784, "unknown BCM5784" }, + { BGE_ASICREV_BCM5785, "unknown BCM5785" }, /* 5754 and 5787 share the same ASIC ID */ { BGE_ASICREV_BCM5787, "unknown BCM5754/5787" }, { BGE_ASICREV_BCM5906, "unknown BCM5906" }, + { BGE_ASICREV_BCM57780, "unknown BCM57780" }, =20 { 0, NULL } }; @@ -309,6 +338,7 @@ #define BGE_IS_5705_PLUS(sc) ((sc)->bge_flags & BGE_FLAG_5705_PLUS) #define BGE_IS_5714_FAMILY(sc) ((sc)->bge_flags & BGE_FLAG_5714_FAMILY) #define BGE_IS_575X_PLUS(sc) ((sc)->bge_flags & BGE_FLAG_575X_PLUS) +#define BGE_IS_5755_PLUS(sc) ((sc)->bge_flags & BGE_FLAG_5755_PLUS) =20 const struct bge_revision * bge_lookup_rev(uint32_t); const struct bge_vendor * bge_lookup_vendor(uint16_t); @@ -1758,8 +1788,7 @@ val =3D BGE_WDMAMODE_ENABLE | BGE_WDMAMODE_ALL_ATTNS; =20 /* Enable host coalescing bug fix. */ - if (sc->bge_asicrev =3D=3D BGE_ASICREV_BCM5755 || - sc->bge_asicrev =3D=3D BGE_ASICREV_BCM5787) + if (BGE_IS_5755_PLUS(sc)) val |=3D 1 << 29; =20 /* Turn on write DMA state machine */ @@ -1768,6 +1797,12 @@ =20 /* Turn on read DMA state machine */ val =3D BGE_RDMAMODE_ENABLE | BGE_RDMAMODE_ALL_ATTNS; + if (sc->bge_asicrev =3D=3D BGE_ASICREV_BCM5784 || + sc->bge_asicrev =3D=3D BGE_ASICREV_BCM5785 || + sc->bge_asicrev =3D=3D BGE_ASICREV_BCM57780) + val |=3D BGE_RDMAMODE_BD_SBD_CRPT_ATTN | + BGE_RDMAMODE_MBUF_RBD_CRPT_ATTN | + BGE_RDMAMODE_MBUF_SBD_CRPT_ATTN; if (sc->bge_flags & BGE_FLAG_PCIE) val |=3D BGE_RDMAMODE_FIFO_LONG_BURST; CSR_WRITE_4(sc, BGE_RDMA_MODE, val); @@ -1790,7 +1825,10 @@ CSR_WRITE_4(sc, BGE_SBDC_MODE, BGE_SBDCMODE_ENABLE); =20 /* Turn on send data completion state machine */ - CSR_WRITE_4(sc, BGE_SDC_MODE, BGE_SDCMODE_ENABLE); + val =3D BGE_SDCMODE_ENABLE; + if (sc->bge_asicrev =3D=3D BGE_ASICREV_BCM5761) + val |=3D BGE_SDCMODE_CDELAY; + CSR_WRITE_4(sc, BGE_SDC_MODE, val); =20 /* Turn on send data initiator state machine */ CSR_WRITE_4(sc, BGE_SDI_MODE, BGE_SDIMODE_ENABLE); @@ -1897,8 +1935,11 @@ const struct bge_vendor *v; uint32_t id; =20 - id =3D pci_read_config(dev, BGE_PCI_MISC_CTL, 4) & - BGE_PCIMISCCTL_ASICREV; + id =3D pci_read_config(dev, BGE_PCI_MISC_CTL, 4) >> + BGE_PCIMISCCTL_ASICREV_SHIFT; + if (BGE_ASICREV(id) =3D=3D BGE_ASICREV_USE_PRODID_REG) + id =3D pci_read_config(dev, + BGE_PCI_PRODID_ASICREV, 4); br =3D bge_lookup_rev(id); v =3D bge_lookup_vendor(vid); { @@ -1915,8 +1956,8 @@ br !=3D NULL ? br->br_name : "NetXtreme Ethernet Controller"); } - snprintf(buf, 96, "%s, %sASIC rev. %#04x", model, - br !=3D NULL ? "" : "unknown ", id >> 16); + snprintf(buf, 96, "%s, %sASIC rev. %#08x", model, + br !=3D NULL ? "" : "unknown ", id); device_set_desc_copy(dev, buf); if (pci_get_subvendor(dev) =3D=3D DELL_VENDORID) sc->bge_flags |=3D BGE_FLAG_NO_3LED; @@ -2411,8 +2452,11 @@ =20 /* Save various chip information. */ sc->bge_chipid =3D - pci_read_config(dev, BGE_PCI_MISC_CTL, 4) & - BGE_PCIMISCCTL_ASICREV; + pci_read_config(dev, BGE_PCI_MISC_CTL, 4) >> + BGE_PCIMISCCTL_ASICREV_SHIFT; + if (BGE_ASICREV(sc->bge_chipid) =3D=3D BGE_ASICREV_USE_PRODID_REG) + sc->bge_chipid =3D pci_read_config(dev, BGE_PCI_PRODID_ASICREV, + 4); sc->bge_asicrev =3D BGE_ASICREV(sc->bge_chipid); sc->bge_chiprev =3D BGE_CHIPREV(sc->bge_chipid); =20 @@ -2431,6 +2475,15 @@ =20 /* Save chipset family. */ switch (sc->bge_asicrev) { + case BGE_ASICREV_BCM5755: + case BGE_ASICREV_BCM5761: + case BGE_ASICREV_BCM5784: + case BGE_ASICREV_BCM5785: + case BGE_ASICREV_BCM5787: + case BGE_ASICREV_BCM57780: + sc->bge_flags |=3D BGE_FLAG_5755_PLUS | BGE_FLAG_575X_PLUS | + BGE_FLAG_5705_PLUS; + break; case BGE_ASICREV_BCM5700: case BGE_ASICREV_BCM5701: case BGE_ASICREV_BCM5703: @@ -2440,12 +2493,11 @@ case BGE_ASICREV_BCM5714_A0: case BGE_ASICREV_BCM5780: case BGE_ASICREV_BCM5714: - sc->bge_flags |=3D BGE_FLAG_5714_FAMILY /* | BGE_FLAG_JUMBO */; - /* FALLTHROUGH */ + sc->bge_flags |=3D BGE_FLAG_5714_FAMILY | BGE_FLAG_575X_PLUS | + BGE_FLAG_5705_PLUS /* | BGE_FLAG_JUMBO */; + break; case BGE_ASICREV_BCM5750: case BGE_ASICREV_BCM5752: - case BGE_ASICREV_BCM5755: - case BGE_ASICREV_BCM5787: case BGE_ASICREV_BCM5906: sc->bge_flags |=3D BGE_FLAG_575X_PLUS; /* FALLTHROUGH */ @@ -2466,6 +2518,8 @@ if (BGE_IS_5705_PLUS(sc) && !(sc->bge_flags & BGE_FLAG_ADJUST_TRIM)) { if (sc->bge_asicrev =3D=3D BGE_ASICREV_BCM5755 || + sc->bge_asicrev =3D=3D BGE_ASICREV_BCM5761 || + sc->bge_asicrev =3D=3D BGE_ASICREV_BCM5784 || sc->bge_asicrev =3D=3D BGE_ASICREV_BCM5787) { if (sc->bge_chipid !=3D BGE_CHIPID_BCM5722_A0) sc->bge_flags |=3D BGE_FLAG_JITTER_BUG; @@ -2873,8 +2927,7 @@ =20 /* Disable fastboot on controllers that support it. */ if (sc->bge_asicrev =3D=3D BGE_ASICREV_BCM5752 || - sc->bge_asicrev =3D=3D BGE_ASICREV_BCM5755 || - sc->bge_asicrev =3D=3D BGE_ASICREV_BCM5787) { + BGE_IS_5755_PLUS(sc)) { if (bootverbose) device_printf(sc->bge_dev, "Disabling fastboot\n"); CSR_WRITE_4(sc, BGE_FASTBOOT_PC, 0x0); @@ -4690,6 +4743,8 @@ =20 printf("Hardware Flags:\n"); if (BGE_IS_575X_PLUS(sc)) + printf(" - 5755 Plus\n"); + if (BGE_IS_575X_PLUS(sc)) printf(" - 575X Plus\n"); if (BGE_IS_5705_PLUS(sc)) printf(" - 5705 Plus\n"); --=20 Stanislav Sedov ST4096-RIPE --Signature=_Tue__6_Oct_2009_20_46_13_+0400_Jz_mOzdr9=3k/ma7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJKy3RaAAoJEKN82nOYvCd0VlkQAIyN+KFrIrkFNdr/V7LKLPkv n7dJhjdffXSbAV/02hDmCUkyJJFc4J0xVy045Xh4mxgkl78pwp7SyL8pR8/5EFz5 lAqte2tQj13Cum1uEsWJ9h/ylm9oKrzfS8i+/nJATJ0HIumAb5oWBRNDeWgD2rI2 WT7PE/zf7tbgOHQbrYaghBqZsvyLloY31lGvfMmCW48qd3GRoe6pGX1rqNMBxJcz Ck6i1jAWra2BHqF3MZhnUMkWsUXXNMf3M+89cgcaMov44o36HkYiN8JGtrQUjfk6 NElh2SMfoOptap6/juu5ZqaXPHG0WB/UDDPYUIhR7cNMR6jUCh4XnZ7hM2RtEpDI 79aNoOlatpTP5/6XrCXbmP54adCH/fPJARNX4B/s344hOAYqrYUNNMGmWxWHTlHk wIBGi1SHWJV5nYsFBELGuR5qvqJsN0/idYPEPsfPqSmRqoXOgutLuKuyeC1e8j+g G6K1IPmPiRNFrP6RdEf5I8OGL3mDpU6jUEfdB2+Vym/Z6DR+2N17xxIOseKcSHiN /QiiGXCV6eX9zSFgGnfNQTKTLVum+P2QhBmoHzqDy9+5Jkoa4SsR6vwLoB9bBsEh m/NDA8a0ETavI35hXz9TG0LVm6Wno+CEju/09G5Arfogu5913pdZsTfg/vl7ANEq +eYk8qqEWyilDj1jyVjv =ZduT -----END PGP SIGNATURE----- --Signature=_Tue__6_Oct_2009_20_46_13_+0400_Jz_mOzdr9=3k/ma7-- From rwatson at FreeBSD.org Tue Oct 6 17:06:38 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Oct 6 17:07:11 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091006161240.GA49940@svzserv.kemerovo.su> References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> Message-ID: On Wed, 7 Oct 2009, Eugene Grosbein wrote: > On Tue, Oct 06, 2009 at 08:28:35PM +0500, rihad wrote: > >> I don't think net.inet.ip.intr_queue_maxlen is relevant to this problem, as >> net.inet.ip.intr_queue_drops is normally zero or very close to it at all >> times. > > When net.isr.direct is 1, this queue is used very seldom. Would you change > it to 0, it will be used extensively. Just to clarify this more specifically: With net.isr.direct set to 0, the netisr will always be used when processing inbound IP packets. With net.isr.direct set to 1, the netisr will only be used for special cases, such as loopback traffic, IPSEC decapsulation, and other processing types where there's a risk of recursive processing. In the default 8.0 configuration, we use one netisr thread; however, you can specify to use multiple threads at boot time. This is not the default currently because we're still researching load distribution schemes, and on current high-performance systems the hardware tends to take care of that already pretty well (i.e., most modern 10gbps cards). Also, ipfw/dummynet have fairly non-granular locking, so adding parallelism won't necessarily help currently. Robert From bms at incunabulum.net Tue Oct 6 17:20:05 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue Oct 6 17:20:10 2009 Subject: kern/137164: [netinet] [patch] assert panic imo_match_source() Message-ID: <200910061720.n96HK44A099715@freefall.freebsd.org> The following reply was made to PR kern/137164; it has been noted by GNATS. From: Bruce Simpson To: Stef Walter Cc: bug-followup@FreeBSD.org, jhanna@pangolin-systems.com Subject: Re: kern/137164: [netinet] [patch] assert panic imo_match_source() Date: Tue, 06 Oct 2009 17:56:54 +0100 Hi Stef, I am about to leave on holiday for two weeks, so I probably won't have time to check this change in. I'm kind of in a last minute rush right now, so it might be better to ping syrinx@ about this change (I don't know if she is still under mentorship or not). If I can get to it during the break (no promises), so far so good. cheers, BMS From rihad at mail.ru Tue Oct 6 17:21:27 2009 From: rihad at mail.ru (rihad) Date: Tue Oct 6 17:21:34 2009 Subject: dummynet dropping too many packets In-Reply-To: References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> Message-ID: <4ACB7C8E.6090905@mail.ru> Robert Watson wrote: > and on current high-performance systems the hardware tends to > take care of that already pretty well (i.e., most modern 10gbps cards). > Do you think that us switching to 10gbps cards would solve the problem discussed? We're currently at 500-550 mbps and rising, so we might as well switch to it now without waiting to hit the ceiling. From oleg at FreeBSD.org Tue Oct 6 17:48:57 2009 From: oleg at FreeBSD.org (Oleg Bulyzhin) Date: Tue Oct 6 17:49:04 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091006101747.GA87655@onelab2.iet.unipi.it> References: <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006093408.GA86830@onelab2.iet.unipi.it> <4ACB0F28.3000906@mail.ru> <20091006101747.GA87655@onelab2.iet.unipi.it> Message-ID: <20091006173039.GA66473@lath.rinet.ru> On Tue, Oct 06, 2009 at 12:17:47PM +0200, Luigi Rizzo wrote: > io_pkt_drop only reports packets dropped to errors (missing pipes, > randomly forced packet drops which you don't use, no buffers and so on). You are mistaken here. io_pkt_drop is total number of packets dropped by dummynet_io(). -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From dfilter at FreeBSD.ORG Tue Oct 6 19:50:04 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Tue Oct 6 19:50:10 2009 Subject: kern/139113: commit references a PR Message-ID: <200910061950.n96Jo2g6032639@freefall.freebsd.org> The following reply was made to PR kern/139113; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/139113: commit references a PR Date: Tue, 6 Oct 2009 19:45:04 +0000 (UTC) Author: qingli Date: Tue Oct 6 19:44:44 2009 New Revision: 197811 URL: http://svn.freebsd.org/changeset/base/197811 Log: MFC 197695 Previously, if an address alias is configured on an interface, and this address alias has a prefix matching that of another address configured on the same interface, then the ARP entry for the alias is not deleted from the ARP table when that address alias is removed. This patch fixes the aforementioned issue. PR: kern/139113 Reviewed by: bz Approved by: re Modified: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) stable/8/sys/dev/xen/xenpci/ (props changed) stable/8/sys/netinet/in.c Modified: stable/8/sys/netinet/in.c ============================================================================== --- stable/8/sys/netinet/in.c Tue Oct 6 18:47:02 2009 (r197810) +++ stable/8/sys/netinet/in.c Tue Oct 6 19:44:44 2009 (r197811) @@ -1060,6 +1060,8 @@ in_scrubprefix(struct in_ifaddr *target) !(target->ia_ifp->if_flags & IFF_LOOPBACK)) { error = ifa_del_loopback_route((struct ifaddr *)target, (struct sockaddr *)&target->ia_addr); + /* remove arp cache */ + arp_ifscrub(target->ia_ifp, IA_SIN(target)->sin_addr.s_addr); } if ((target->ia_flags & IFA_ROUTE) == 0) { @@ -1082,8 +1084,6 @@ in_scrubprefix(struct in_ifaddr *target) prefix = target->ia_addr.sin_addr; mask = target->ia_sockmask.sin_addr; prefix.s_addr &= mask.s_addr; - /* remove arp cache */ - arp_ifscrub(target->ia_ifp, IA_SIN(target)->sin_addr.s_addr); } IN_IFADDR_RLOCK(); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From rizzo at iet.unipi.it Tue Oct 6 20:58:32 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Tue Oct 6 20:58:39 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091006173039.GA66473@lath.rinet.ru> References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006093408.GA86830@onelab2.iet.unipi.it> <4ACB0F28.3000906@mail.ru> <20091006101747.GA87655@onelab2.iet.unipi.it> <20091006173039.GA66473@lath.rinet.ru> Message-ID: <20091006210513.GA14620@onelab2.iet.unipi.it> On Tue, Oct 06, 2009 at 09:30:39PM +0400, Oleg Bulyzhin wrote: > On Tue, Oct 06, 2009 at 12:17:47PM +0200, Luigi Rizzo wrote: > > > io_pkt_drop only reports packets dropped to errors (missing pipes, > > randomly forced packet drops which you don't use, no buffers and so on). > > You are mistaken here. io_pkt_drop is total number of packets dropped by > dummynet_io(). hmm... you are right. From dhorn2000 at gmail.com Wed Oct 7 02:43:04 2009 From: dhorn2000 at gmail.com (David Horn) Date: Wed Oct 7 02:43:11 2009 Subject: ezwlansetup sh script (8.0) Message-ID: <25ff90d60910061943g75ab90bcs785659f2c2ec40f4@mail.gmail.com> I have recently been using my laptop wifi in several new locations and decided it was time to write a user friendly interactive shell script to manage the necessary configuration file entries that govern wlan connections in freebsd 8+, and to manage wpa_supplicant, etc. This is just a first draft (no warranties!), but I wanted to get some feedback before I continue. It still needs some formatting/style changes, and likely re-wording of some of the prompts. Please let me know if: a) It eats your cat or config files b) It works and/or you find it useful c) It sucks, and you find zero value since you have memorized wpa_supplicant.conf and do not need a user friendly front end d) ok for a start, but you really want feature abc e) there is already a duplication of effort going on somewhere else # Revision=0.1 (Alpha) Works, but not well tested yet # # Requires: FreeBSD 8+ # # Designed for the mainstream end-user workstation scenarios, # not for any of the server hostap, multi-bss, lagg, vlan, gateway, WDS, or # other setups which require static configuration # # Works with: # - WEP, WPA, WPA2, NONE Authentication - Station (STA) mode ONLY # - multiple Access-Point (BSS) profiles in wpa_supplicant.conf # - single wlanX interface per wireless nic # - multiple wireless nics (e.g. iwn0 and ath0) # - with/without existing /etc/rc.conf entries # - with/without existing /etc/wpa_supplicant entries # - demand-load wireless nic kernel module + add to loader.conf # - priority field per profile setting # - Hidden SSID per profile setting # - rescan and display sorted AP list (sorted by signal strength) # - Display scan results with detected authentication values # - Ad-Hoc (As a static rc.conf entry only) + switch ibss<->bss mode # # Broken with # - WPS # - WPA-EAP/802.1x - tbd # - IBSS with encryption (WEP/WPA static key) Full sh script (ezwlansetup.sh) is here: http://sites.google.com/site/freebsdattachments/home/ezwlansetup.sh ./ezwlansetup.sh --help for usage information ---Dave H From universite at ukr.net Wed Oct 7 07:03:31 2009 From: universite at ukr.net (Vladislav V. Prodan) Date: Wed Oct 7 07:03:38 2009 Subject: Packages with the wrong source Message-ID: <4ACC3D3B.5080508@ukr.net> I have two channels on the Internet PPPoE - tun1 and tun2. When you start ntpd, incoming packets begin to crumble with the first ISP, although requests come from the 2-nd ISP 23:40:53.548840 IP (tos 0x40, ttl 58, id 0, offset 0, flags [DF], proto UDP (17), length 76) 192.168.30.1.ntp > .ntp: [udp sum ok] NTPv3, length 48 symmetric active, Leap indicator: (0), Stratum 3, poll 4s, precision -19 Root Delay: 0.021423, Root dispersion: 0.086944, Reference-ID: Te.NeT.UA Reference Timestamp: 3460219701.661973714 (2009/08/25 23:08:21) Originator Timestamp: 3460221653.546850204 (2009/08/25 23:40:53) Receive Timestamp: 3460221653.552442133 (2009/08/25 23:40:53) Transmit Timestamp: 3460221653.552893817 (2009/08/25 23:40:53) Originator - Receive Timestamp: +0.005591936 Originator - Transmit Timestamp: +0.006043639 And these packages bandwidth demands grow to 2MBps Only helps to turn off ntpd. The only problem with the ntp packets The problem suddenly appears and as suddenly disappears. There are ideas on how to fix this problem? # uname -a FreeBSD mary-teresa.xxxxxxxxxxx 8.0-BETA4 FreeBSD 8.0-BETA4 #0: Sun Sep 13 03:05:09 EEST 2009 vlad11@mary-teresa.xxxxxxxxxxx:/usr/obj/usr/src/sys/mary-teresa.18 amd64 # ntptrace -n 192.168.30.1 192.168.30.1: stratum 3, offset -0.000105, root distance 0.012885 [2-nd ISP] 195.138.zzz.34: stratum 2, offset 0.000140, root distance 0.012610 62.149.0.30: stratum 1, offset 0.000000, root distance 0.000000, refid 'GPS' # netstat -rn | grep 192.168. 10.0.0.0/8 192.168.61.250 UGS 0 375059 vr1 192.168.0.0/16 192.168.61.250 UGS 0 48072705 vr1 192.168.60.0/23 link#3 U 0 790 vr1 192.168.60.194 link#4 UHS 0 3491 lo0 # netstat -rn | grep UGS default 89.209.95.254 UGS 0 232097628 tun1 10.0.0.0/8 192.168.61.250 UGS 0 375120 vr1 192.168.0.0/16 192.168.61.250 UGS 0 49891561 vr1 1-st ISP <--- tun1 <-- vr0 -- [router] -- vr1 --> tun2 --> 2-nd ISP # ifconfig vr0 vr0: flags=8843 metric 0 mtu 1500 options=2808 ether 00:11:95:ff:a7:c0 media: Ethernet autoselect (100baseTX ) status: active # ifconfig vr1 vr1: flags=8943 metric 0 mtu 1500 options=2808 ether 00:02:44:8b:89:40 inet 192.168.60.194 netmask 0xfffffe00 broadcast 192.168.61.255 media: Ethernet autoselect (100baseTX ) status: active # ifconfig tun1 tun1: flags=8051 metric 0 mtu 1492 inet 89.209.sss.sss --> 89.209.95.254 netmask 0xffffffff Opened by PID 1582 # ifconfig tun2 tun2: flags=8051 metric 0 mtu 1492 inet 85.238.sss.sss --> 195.138.80.134 netmask 0xffffffff Opened by PID 97047 From rihad at mail.ru Wed Oct 7 08:46:42 2009 From: rihad at mail.ru (rihad) Date: Wed Oct 7 08:46:50 2009 Subject: dummynet dropping too many packets In-Reply-To: References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> Message-ID: <4ACC5563.602@mail.ru> Robert Watson wrote: > > On Wed, 7 Oct 2009, Eugene Grosbein wrote: > >> On Tue, Oct 06, 2009 at 08:28:35PM +0500, rihad wrote: >> >>> I don't think net.inet.ip.intr_queue_maxlen is relevant to this >>> problem, as net.inet.ip.intr_queue_drops is normally zero or very >>> close to it at all times. >> >> When net.isr.direct is 1, this queue is used very seldom. Would you >> change it to 0, it will be used extensively. > > Just to clarify this more specifically: > > With net.isr.direct set to 0, the netisr will always be used when > processing inbound IP packets. > Maybe I've done something wrong, but setting net.isr.direct=0 on a live system hasn't yet overrun the default queue of 50 @460-470 mbit/s: $ sysctl net.inet.ip | fgrep intr net.inet.ip.intr_queue_maxlen: 50 net.inet.ip.intr_queue_drops: 0 $ sysctl net.isr.direct net.isr.direct: 0 I've yet to test how this direct=0 improves extensive dummynet drops. From rihad at mail.ru Wed Oct 7 08:51:52 2009 From: rihad at mail.ru (rihad) Date: Wed Oct 7 08:52:00 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACC5563.602@mail.ru> References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> <4ACC5563.602@mail.ru> Message-ID: <4ACC56A6.1030808@mail.ru> rihad wrote: > I've yet to test how this direct=0 improves extensive dummynet drops. > Ooops... After a couple of minutes, suddenly: net.inet.ip.intr_queue_drops: 1284 Bumped it up a bit. From oleg at FreeBSD.org Wed Oct 7 08:59:04 2009 From: oleg at FreeBSD.org (Oleg Bulyzhin) Date: Wed Oct 7 08:59:11 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AC8A76B.3050502@mail.ru> References: <4AC8A76B.3050502@mail.ru> Message-ID: <20091007085902.GA88982@lath.rinet.ru> Please show your 'sysctl net.inet.ip' output. -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From rwatson at FreeBSD.org Wed Oct 7 09:01:20 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Oct 7 09:01:52 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACC56A6.1030808@mail.ru> References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> <4ACC5563.602@mail.ru> <4ACC56A6.1030808@mail.ru> Message-ID: On Wed, 7 Oct 2009, rihad wrote: > rihad wrote: >> I've yet to test how this direct=0 improves extensive dummynet drops. > > Ooops... After a couple of minutes, suddenly: > > net.inet.ip.intr_queue_drops: 1284 > > Bumped it up a bit. Yes, I was going to suggest that moving to deferred dispatch has probably simply moved the drops to a new spot, the queue between the ithreads and the netisr thread. In your setup, how many network interfaces are in use, and what drivers? If what's happening is that you're maxing out a CPU then moving to multiple netisrs might help if your card supports generating flow IDs, but most lower-end cards don't. I have patches to generate those flow IDs in software rather than hardware, but there are some downsides to doing so, not least that it takes cache line misses on the packet that generally make up a lot of the cost of processing the packet. My experience with most reasonable cards is that letting them doing the work distribution with RSS and use multiple ithreads is a more performant strategy than using software work distribution on current systems, though. Someone has probably asked for this already, but -- could you send a snapshot of the top -SH output in the steady state? Let top run for a few minutes and then copy/paste the first 10-20 lines into an e-mail. Robert N M Watson Computer Laboratory University of Cambridge From rihad at mail.ru Wed Oct 7 09:22:57 2009 From: rihad at mail.ru (rihad) Date: Wed Oct 7 09:23:04 2009 Subject: dummynet dropping too many packets In-Reply-To: References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> <4ACC5563.602@mail.ru> <4ACC56A6.1030808@mail.ru> Message-ID: <4ACC5DEC.1010006@mail.ru> Robert Watson wrote: > On Wed, 7 Oct 2009, rihad wrote: > >> rihad wrote: >>> I've yet to test how this direct=0 improves extensive dummynet drops. >> >> Ooops... After a couple of minutes, suddenly: >> >> net.inet.ip.intr_queue_drops: 1284 >> >> Bumped it up a bit. > > Yes, I was going to suggest that moving to deferred dispatch has > probably simply moved the drops to a new spot, the queue between the > ithreads and the netisr thread. In your setup, how many network > interfaces are in use, and what drivers? > bce -- Broadcom NetXtreme II (BCM5706/BCM5708) PCI/PCIe Gigabit Ethernet adapter driver device bce compiled into a 7.1-RELEASE-p8 kernel. 2 network cards: bce0 used for ~400-500 mbit/s input, bce1 for output, i.e. acting as a smart router. It has 2 quad core CPUs. Now the probability of drops (as monitored by netstat -s's "output packets dropped due to no bufs, etc.") is definitely a function of traffic load and the number of items in a ipfw table. I've just decreased the size of the two tables from ~2600 to ~1800 each and the drops instantly went away, even though the traffic passing through the box didn't decrease, it even increased a bit due to now shaping fewer clients (luckily "ipfw pipe tablearg" passes packets failing a table lookup untouched). > If what's happening is that you're maxing out a CPU then moving to > multiple netisrs might help if your card supports generating flow IDs, > but most lower-end cards don't. I have patches to generate those flow > IDs in software rather than hardware, but there are some downsides to > doing so, not least that it takes cache line misses on the packet that > generally make up a lot of the cost of processing the packet. > > My experience with most reasonable cards is that letting them doing the > work distribution with RSS and use multiple ithreads is a more > performant strategy than using software work distribution on current > systems, though. > So should we prefer a bunch of expensive quality 10 gig cards? Any you would recommend? > Someone has probably asked for this already, but -- could you send a > snapshot of the top -SH output in the steady state? Let top run for a > few minutes and then copy/paste the first 10-20 lines into an e-mail. > Sure. Mind you: now there's only 1800 entries in each of the two ipfw tables, so any drops have stopped. But it only takes another 200-300 entries to start dropping. 155 processes: 10 running, 129 sleeping, 16 waiting CPU: 2.4% user, 0.0% nice, 2.0% system, 9.3% interrupt, 86.2% idle Mem: 1691M Active, 1491M Inact, 454M Wired, 130M Cache, 214M Buf, 170M Free Swap: 2048M Total, 12K Used, 2048M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 15 root 171 ki31 0K 16K CPU3 3 22.4H 97.85% idle: cpu3 14 root 171 ki31 0K 16K CPU4 4 23.0H 96.29% idle: cpu4 12 root 171 ki31 0K 16K CPU6 6 23.8H 94.58% idle: cpu6 16 root 171 ki31 0K 16K CPU2 2 22.5H 90.72% idle: cpu2 13 root 171 ki31 0K 16K CPU5 5 23.4H 90.58% idle: cpu5 18 root 171 ki31 0K 16K RUN 0 20.3H 85.60% idle: cpu0 17 root 171 ki31 0K 16K CPU1 1 910:03 78.37% idle: cpu1 11 root 171 ki31 0K 16K CPU7 7 23.8H 65.62% idle: cpu7 21 root -44 - 0K 16K CPU7 7 19:03 48.34% swi1: net 29 root -68 - 0K 16K WAIT 1 515:49 19.63% irq256: bce0 31 root -68 - 0K 16K WAIT 2 56:05 5.52% irq257: bce1 19 root -32 - 0K 16K WAIT 5 50:05 3.86% swi4: clock sio 983 flowtools 44 0 12112K 6440K select 0 13:20 0.15% flow-capture 465 root -68 - 0K 16K - 3 51:19 0.00% dummynet 3 root -8 - 0K 16K - 1 7:41 0.00% g_up 4 root -8 - 0K 16K - 2 7:14 0.00% g_down 30 root -64 - 0K 16K WAIT 6 5:30 0.00% irq16: mfi0 From rihad at mail.ru Wed Oct 7 09:23:49 2009 From: rihad at mail.ru (rihad) Date: Wed Oct 7 09:23:58 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091007085902.GA88982@lath.rinet.ru> References: <4AC8A76B.3050502@mail.ru> <20091007085902.GA88982@lath.rinet.ru> Message-ID: <4ACC5E23.8090405@mail.ru> Oleg Bulyzhin wrote: > Please show your 'sysctl net.inet.ip' output. > net.inet.ip.portrange.randomtime: 45 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomized: 1 net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.first: 49152 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.forwarding: 1 net.inet.ip.redirect: 1 net.inet.ip.ttl: 64 net.inet.ip.rtexpire: 3600 net.inet.ip.rtminexpire: 10 net.inet.ip.rtmaxcache: 128 net.inet.ip.sourceroute: 0 net.inet.ip.intr_queue_maxlen: 300 net.inet.ip.intr_queue_drops: 1365 net.inet.ip.accept_sourceroute: 0 net.inet.ip.keepfaith: 0 net.inet.ip.gifttl: 30 net.inet.ip.same_prefix_carp_only: 0 net.inet.ip.subnets_are_local: 0 net.inet.ip.fastforwarding: 0 net.inet.ip.fw.dyn_keepalive: 1 net.inet.ip.fw.dyn_short_lifetime: 5 net.inet.ip.fw.dyn_udp_lifetime: 10 net.inet.ip.fw.dyn_rst_lifetime: 1 net.inet.ip.fw.dyn_fin_lifetime: 1 net.inet.ip.fw.dyn_syn_lifetime: 20 net.inet.ip.fw.dyn_ack_lifetime: 300 net.inet.ip.fw.static_count: 12 net.inet.ip.fw.dyn_max: 4096 net.inet.ip.fw.dyn_count: 0 net.inet.ip.fw.curr_dyn_buckets: 256 net.inet.ip.fw.dyn_buckets: 256 net.inet.ip.fw.default_rule: 65535 net.inet.ip.fw.verbose_limit: 0 net.inet.ip.fw.verbose: 0 net.inet.ip.fw.debug: 1 net.inet.ip.fw.one_pass: 0 net.inet.ip.fw.autoinc_step: 100 net.inet.ip.fw.enable: 1 net.inet.ip.maxfragpackets: 3472 net.inet.ip.maxfragsperpacket: 16 net.inet.ip.fragpackets: 0 net.inet.ip.check_interface: 0 net.inet.ip.random_id: 0 net.inet.ip.sendsourcequench: 0 net.inet.ip.process_options: 1 net.inet.ip.dummynet.debug: 0 net.inet.ip.dummynet.pipe_byte_limit: 1048576 net.inet.ip.dummynet.pipe_slot_limit: 2000 net.inet.ip.dummynet.io_pkt_drop: 4515 net.inet.ip.dummynet.io_pkt_fast: 120785085 net.inet.ip.dummynet.io_pkt: 639360193 net.inet.ip.dummynet.io_fast: 1 net.inet.ip.dummynet.tick_lost: 0 net.inet.ip.dummynet.tick_diff: 4252218 net.inet.ip.dummynet.tick_adjustment: 950800 net.inet.ip.dummynet.tick_delta_sum: 173 net.inet.ip.dummynet.tick_delta: 502 net.inet.ip.dummynet.red_max_pkt_size: 1500 net.inet.ip.dummynet.red_avg_pkt_size: 512 net.inet.ip.dummynet.red_lookup_depth: 256 net.inet.ip.dummynet.max_chain_len: 16 net.inet.ip.dummynet.expire: 1 net.inet.ip.dummynet.search_steps: 710716767 net.inet.ip.dummynet.searches: 639360196 net.inet.ip.dummynet.extract_heap: 0 net.inet.ip.dummynet.ready_heap: 496 net.inet.ip.dummynet.curr_time: 181442521 net.inet.ip.dummynet.hash_size: 65536 From rwatson at FreeBSD.org Wed Oct 7 09:36:59 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Oct 7 09:37:05 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACC5DEC.1010006@mail.ru> References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> <4ACC5563.602@mail.ru> <4ACC56A6.1030808@mail.ru> <4ACC5DEC.1010006@mail.ru> Message-ID: On Wed, 7 Oct 2009, rihad wrote: >> snapshot of the top -SH output in the steady state? Let top run for a few >> minutes and then copy/paste the first 10-20 lines into an e-mail. >> > Sure. Mind you: now there's only 1800 entries in each of the two ipfw > tables, so any drops have stopped. But it only takes another 200-300 entries > to start dropping. Could you do the same in the net.isr.direct=1 configuration so we can compare? Robert > > 155 processes: 10 running, 129 sleeping, 16 waiting > CPU: 2.4% user, 0.0% nice, 2.0% system, 9.3% interrupt, 86.2% idle > Mem: 1691M Active, 1491M Inact, 454M Wired, 130M Cache, 214M Buf, 170M Free > Swap: 2048M Total, 12K Used, 2048M Free > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 15 root 171 ki31 0K 16K CPU3 3 22.4H 97.85% idle: cpu3 > 14 root 171 ki31 0K 16K CPU4 4 23.0H 96.29% idle: cpu4 > 12 root 171 ki31 0K 16K CPU6 6 23.8H 94.58% idle: cpu6 > 16 root 171 ki31 0K 16K CPU2 2 22.5H 90.72% idle: cpu2 > 13 root 171 ki31 0K 16K CPU5 5 23.4H 90.58% idle: cpu5 > 18 root 171 ki31 0K 16K RUN 0 20.3H 85.60% idle: cpu0 > 17 root 171 ki31 0K 16K CPU1 1 910:03 78.37% idle: cpu1 > 11 root 171 ki31 0K 16K CPU7 7 23.8H 65.62% idle: cpu7 > 21 root -44 - 0K 16K CPU7 7 19:03 48.34% swi1: net > 29 root -68 - 0K 16K WAIT 1 515:49 19.63% irq256: bce0 > 31 root -68 - 0K 16K WAIT 2 56:05 5.52% irq257: bce1 > 19 root -32 - 0K 16K WAIT 5 50:05 3.86% swi4: clock > sio > 983 flowtools 44 0 12112K 6440K select 0 13:20 0.15% flow-capture > 465 root -68 - 0K 16K - 3 51:19 0.00% dummynet > 3 root -8 - 0K 16K - 1 7:41 0.00% g_up > 4 root -8 - 0K 16K - 2 7:14 0.00% g_down > 30 root -64 - 0K 16K WAIT 6 5:30 0.00% irq16: mfi0 > > From rihad at mail.ru Wed Oct 7 09:55:50 2009 From: rihad at mail.ru (rihad) Date: Wed Oct 7 09:55:56 2009 Subject: dummynet dropping too many packets In-Reply-To: References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> <4ACC5563.602@mail.ru> <4ACC56A6.1030808@mail.ru> <4ACC5DEC.1010006@mail.ru> Message-ID: <4ACC65A0.7030900@mail.ru> Robert Watson wrote: > > On Wed, 7 Oct 2009, rihad wrote: > >>> snapshot of the top -SH output in the steady state? Let top run for >>> a few minutes and then copy/paste the first 10-20 lines into an e-mail. >>> >> Sure. Mind you: now there's only 1800 entries in each of the two ipfw >> tables, so any drops have stopped. But it only takes another 200-300 >> entries to start dropping. > > Could you do the same in the net.isr.direct=1 configuration so we can > compare? > net.isr.direct=1: last pid: 92152; load averages: 0.99, 1.18, 1.15 up 1+01:42:28 14:53:09 162 processes: 9 running, 136 sleeping, 17 waiting CPU: 2.1% user, 0.0% nice, 5.4% system, 7.0% interrupt, 85.5% idle Mem: 1693M Active, 1429M Inact, 447M Wired, 197M Cache, 214M Buf, 170M Free Swap: 2048M Total, 12K Used, 2048M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root 171 ki31 0K 16K CPU6 6 24.3H 100.00% idle: cpu6 13 root 171 ki31 0K 16K CPU5 5 23.8H 95.95% idle: cpu5 14 root 171 ki31 0K 16K CPU4 4 23.4H 93.12% idle: cpu4 16 root 171 ki31 0K 16K CPU2 2 23.0H 90.19% idle: cpu2 11 root 171 ki31 0K 16K CPU7 7 24.2H 87.26% idle: cpu7 15 root 171 ki31 0K 16K CPU3 3 22.8H 86.18% idle: cpu3 18 root 171 ki31 0K 16K RUN 0 20.6H 84.96% idle: cpu0 17 root 171 ki31 0K 16K CPU1 1 933:23 47.85% idle: cpu1 29 root -68 - 0K 16K WAIT 1 522:02 46.88% irq256: bce0 465 root -68 - 0K 16K - 7 55:15 12.65% dummynet 31 root -68 - 0K 16K WAIT 2 57:29 4.74% irq257: bce1 21 root -44 - 0K 16K WAIT 0 34:55 4.64% swi1: net 19 root -32 - 0K 16K WAIT 4 51:41 3.96% swi4: clock sio 30 root -64 - 0K 16K WAIT 6 5:43 0.73% irq16: mfi0 Almost 2000 entries in the table, traffic load= 420-430 mbps, drops haven't yet started. Previous net.isr.direct=0: > >> >> 155 processes: 10 running, 129 sleeping, 16 waiting >> CPU: 2.4% user, 0.0% nice, 2.0% system, 9.3% interrupt, 86.2% idle >> Mem: 1691M Active, 1491M Inact, 454M Wired, 130M Cache, 214M Buf, 170M >> Free >> Swap: 2048M Total, 12K Used, 2048M Free >> >> PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND >> 15 root 171 ki31 0K 16K CPU3 3 22.4H 97.85% idle: cpu3 >> 14 root 171 ki31 0K 16K CPU4 4 23.0H 96.29% idle: cpu4 >> 12 root 171 ki31 0K 16K CPU6 6 23.8H 94.58% idle: cpu6 >> 16 root 171 ki31 0K 16K CPU2 2 22.5H 90.72% idle: cpu2 >> 13 root 171 ki31 0K 16K CPU5 5 23.4H 90.58% idle: cpu5 >> 18 root 171 ki31 0K 16K RUN 0 20.3H 85.60% idle: cpu0 >> 17 root 171 ki31 0K 16K CPU1 1 910:03 78.37% idle: cpu1 >> 11 root 171 ki31 0K 16K CPU7 7 23.8H 65.62% idle: cpu7 >> 21 root -44 - 0K 16K CPU7 7 19:03 48.34% swi1: net >> 29 root -68 - 0K 16K WAIT 1 515:49 19.63% irq256: >> bce0 >> 31 root -68 - 0K 16K WAIT 2 56:05 5.52% irq257: >> bce1 >> 19 root -32 - 0K 16K WAIT 5 50:05 3.86% swi4: >> clock sio >> 983 flowtools 44 0 12112K 6440K select 0 13:20 0.15% >> flow-capture >> 465 root -68 - 0K 16K - 3 51:19 0.00% dummynet >> 3 root -8 - 0K 16K - 1 7:41 0.00% g_up >> 4 root -8 - 0K 16K - 2 7:14 0.00% g_down >> 30 root -64 - 0K 16K WAIT 6 5:30 0.00% irq16: mfi0 >> >> > > From oleg at FreeBSD.org Wed Oct 7 10:05:07 2009 From: oleg at FreeBSD.org (Oleg Bulyzhin) Date: Wed Oct 7 10:05:13 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACC5E23.8090405@mail.ru> References: <4AC8A76B.3050502@mail.ru> <20091007085902.GA88982@lath.rinet.ru> <4ACC5E23.8090405@mail.ru> Message-ID: <20091007100503.GB88982@lath.rinet.ru> On Wed, Oct 07, 2009 at 02:23:47PM +0500, rihad wrote: Few questions: 1) why are you not using fastforwarding? 2) search_steps/searches ratio is not that good, are you using 'buckets' keyword in your pipe configuration? 3) you have net.inet.ip.fw.one_pass = 0, is it intended? -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From rihad at mail.ru Wed Oct 7 10:16:32 2009 From: rihad at mail.ru (rihad) Date: Wed Oct 7 10:16:39 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091007100503.GB88982@lath.rinet.ru> References: <4AC8A76B.3050502@mail.ru> <20091007085902.GA88982@lath.rinet.ru> <4ACC5E23.8090405@mail.ru> <20091007100503.GB88982@lath.rinet.ru> Message-ID: <4ACC6A7B.5050808@mail.ru> Oleg Bulyzhin wrote: > On Wed, Oct 07, 2009 at 02:23:47PM +0500, rihad wrote: > > Few questions: > 1) why are you not using fastforwarding? > 2) search_steps/searches ratio is not that good, are you using 'buckets' > keyword in your pipe configuration? > 3) you have net.inet.ip.fw.one_pass = 0, is it intended? > 1) and 3): the box does traffic accounting and shaping, so I need one_pass=0 to do both ngtee and pipes. 2) Hm, I'm not using "buckets", but rather net.inet.ip.dummynet.hash_size. It's at default, 64. I've tried setting net.inet.ip.dummynet.hash_size=65536 in sysctl.conf but somehow it was still 64 after reboot, so I left it at 64. Should I make it 128? 256? Does it matter that much? The load is at approx. 70-120 consumers per pipe, so I thought 64 bucket size was enough. Here's how I've been monitoring the pipe load interactively: #!/usr/local/bin/bash while :; do ( buff="$(ipfw pipe show | grep -E '^[[:digit:]]+:' | sort -n -k8,8 -r)" online="$(mysql -Bs -u... -p... dbname -e"select count(*) from online")" clear echo "$buff" echo "$buff" | awk '{sum+=$8} END {printf "QLoad: %d/%d\n", sum, '"$online"'}' netstat -m | fgrep -w 'mbuf clusters in use' ) | dd 2>/dev/null if [ -t 0 ]; then read -s -n 1 -t 15 else sleep 15 fi done Public domain ;-) From rihad at mail.ru Wed Oct 7 10:27:41 2009 From: rihad at mail.ru (rihad) Date: Wed Oct 7 10:27:47 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACC5DEC.1010006@mail.ru> References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> <4ACC5563.602@mail.ru> <4ACC56A6.1030808@mail.ru> <4ACC5DEC.1010006@mail.ru> Message-ID: <4ACC6D17.7000405@mail.ru> rihad wrote: > Now the probability of drops (as monitored by netstat -s's "output > packets dropped due to no bufs, etc.") is definitely a function of > traffic load and the number of items in a ipfw table. I've just > decreased the size of the two tables from ~2600 to ~1800 each and the > drops instantly went away, even though the traffic passing through the > box didn't decrease, it even increased a bit due to now shaping fewer > clients (luckily "ipfw pipe tablearg" passes packets failing a table > lookup untouched). > ~2100 users in each of the two tables, Drops have started coming in but at a a very very slow rate, like 30-150 in a single burst every 10-20 minutes. Run every 10 seconds: $ while :; do netstat -s 2>/dev/null | fgrep -w "output packets dropped"; sleep 10; done 30900 output packets dropped due to no bufs, etc. ... 250-300 lines skipped 30923 output packets dropped due to no bufs, etc. ... 50-100 lines skipped 30953 output packets dropped due to no bufs, etc. 31165 output packets dropped due to no bufs, etc. 31165 output packets dropped due to no bufs, etc. 31165 output packets dropped due to no bufs, etc. 31165 output packets dropped due to no bufs, etc. 31165 output packets dropped due to no bufs, etc. 31165 output packets dropped due to no bufs, etc. 31165 output packets dropped due to no bufs, etc. 31165 output packets dropped due to no bufs, etc. 31165 output packets dropped due to no bufs, etc. 31165 output packets dropped due to no bufs, etc. 31165 output packets dropped due to no bufs, etc. 31165 output packets dropped due to no bufs, etc. 31165 output packets dropped due to no bufs, etc. 31165 output packets dropped due to no bufs, etc. 31165 output packets dropped due to no bufs, etc. 31165 output packets dropped due to no bufs, etc. 31165 output packets dropped due to no bufs, etc. 31165 output packets dropped due to no bufs, etc. 31165 output packets dropped due to no bufs, etc. 31165 output packets dropped due to no bufs, etc. 31165 output packets dropped due to no bufs, etc. 31165 output packets dropped due to no bufs, etc. 31165 output packets dropped due to no bufs, etc. 31165 output packets dropped due to no bufs, etc. 31444 output packets dropped due to no bufs, etc. 31444 output packets dropped due to no bufs, etc. 31444 output packets dropped due to no bufs, etc. 31549 output packets dropped due to no bufs, etc. 31549 output packets dropped due to no bufs, etc. 31549 output packets dropped due to no bufs, etc. 31549 output packets dropped due to no bufs, etc. 31549 output packets dropped due to no bufs, etc. 31549 output packets dropped due to no bufs, etc. 31678 output packets dropped due to no bufs, etc. 31678 output packets dropped due to no bufs, etc. 31678 output packets dropped due to no bufs, etc. 31678 output packets dropped due to no bufs, etc. 31678 output packets dropped due to no bufs, etc. 31678 output packets dropped due to no bufs, etc. 31678 output packets dropped due to no bufs, etc. 31678 output packets dropped due to no bufs, etc. So the larger the number of users (increased at about 1-2 every 10 seconds as users log in and out) the shorter the pause between the bursts. net.isr.direct=0 top -SH: last pid: 2528; load averages: 0.69, 0.89, 0.96 up 1+02:15:20 15:26:01 165 processes: 12 running, 137 sleeping, 16 waiting CPU: 9.5% user, 0.0% nice, 3.8% system, 6.9% interrupt, 79.9% idle Mem: 1726M Active, 1453M Inact, 433M Wired, 178M Cache, 214M Buf, 145M Free Swap: 2048M Total, 12K Used, 2048M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root 171 ki31 0K 16K RUN 6 24.8H 100.00% idle: cpu6 11 root 171 ki31 0K 16K CPU7 7 24.7H 98.29% idle: cpu7 13 root 171 ki31 0K 16K CPU5 5 24.3H 98.19% idle: cpu5 14 root 171 ki31 0K 16K CPU4 4 23.9H 95.41% idle: cpu4 15 root 171 ki31 0K 16K CPU3 3 23.3H 93.55% idle: cpu3 16 root 171 ki31 0K 16K CPU2 2 23.4H 87.06% idle: cpu2 18 root 171 ki31 0K 16K CPU0 0 21.1H 86.72% idle: cpu0 29 root -68 - 0K 16K CPU1 1 537:45 47.61% irq256: bce0 17 root 171 ki31 0K 16K RUN 1 948:22 43.12% idle: cpu1 19 root -32 - 0K 16K WAIT 4 53:10 4.25% swi4: clock sio 31 root -68 - 0K 16K WAIT 2 58:44 3.86% irq257: bce1 465 root -68 - 0K 16K CPU3 3 59:02 1.51% dummynet 21 root -44 - 0K 16K WAIT 0 34:58 0.00% swi1: net 3 root -8 - 0K 16K - 0 8:15 0.00% g_up Dummynet's WCPU is mostly 0-4%, but might jump to 6-12% sometimes, depending on which fraction of the second you look at it. From rihad at mail.ru Wed Oct 7 10:35:13 2009 From: rihad at mail.ru (rihad) Date: Wed Oct 7 10:35:21 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACC6D17.7000405@mail.ru> References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> <4ACC5563.602@mail.ru> <4ACC56A6.1030808@mail.ru> <4ACC5DEC.1010006@mail.ru> <4ACC6D17.7000405@mail.ru> Message-ID: <4ACC6EDE.4040305@mail.ru> rihad wrote: > net.isr.direct=0 Sorry, net.isr.direct=1 I forgot to revert it back after copy'n'pasting top -SH for Mr. Robert. > top -SH: > last pid: 2528; load averages: 0.69, 0.89, 0.96 > up 1+02:15:20 15:26:01 > 165 processes: 12 running, 137 sleeping, 16 waiting > CPU: 9.5% user, 0.0% nice, 3.8% system, 6.9% interrupt, 79.9% idle > Mem: 1726M Active, 1453M Inact, 433M Wired, 178M Cache, 214M Buf, 145M Free > Swap: 2048M Total, 12K Used, 2048M Free > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 12 root 171 ki31 0K 16K RUN 6 24.8H 100.00% idle: cpu6 > 11 root 171 ki31 0K 16K CPU7 7 24.7H 98.29% idle: cpu7 > 13 root 171 ki31 0K 16K CPU5 5 24.3H 98.19% idle: cpu5 > 14 root 171 ki31 0K 16K CPU4 4 23.9H 95.41% idle: cpu4 > 15 root 171 ki31 0K 16K CPU3 3 23.3H 93.55% idle: cpu3 > 16 root 171 ki31 0K 16K CPU2 2 23.4H 87.06% idle: cpu2 > 18 root 171 ki31 0K 16K CPU0 0 21.1H 86.72% idle: cpu0 > 29 root -68 - 0K 16K CPU1 1 537:45 47.61% irq256: bce0 > 17 root 171 ki31 0K 16K RUN 1 948:22 43.12% idle: cpu1 > 19 root -32 - 0K 16K WAIT 4 53:10 4.25% swi4: > clock sio > 31 root -68 - 0K 16K WAIT 2 58:44 3.86% irq257: bce1 > 465 root -68 - 0K 16K CPU3 3 59:02 1.51% dummynet > 21 root -44 - 0K 16K WAIT 0 34:58 0.00% swi1: net > 3 root -8 - 0K 16K - 0 8:15 0.00% g_up > > > Dummynet's WCPU is mostly 0-4%, but might jump to 6-12% sometimes, > depending on which fraction of the second you look at it. > From oleg at FreeBSD.org Wed Oct 7 10:45:27 2009 From: oleg at FreeBSD.org (Oleg Bulyzhin) Date: Wed Oct 7 10:45:33 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACC6A7B.5050808@mail.ru> References: <4AC8A76B.3050502@mail.ru> <20091007085902.GA88982@lath.rinet.ru> <4ACC5E23.8090405@mail.ru> <20091007100503.GB88982@lath.rinet.ru> <4ACC6A7B.5050808@mail.ru> Message-ID: <20091007104525.GC88982@lath.rinet.ru> On Wed, Oct 07, 2009 at 03:16:27PM +0500, rihad wrote: > Oleg Bulyzhin wrote: > > On Wed, Oct 07, 2009 at 02:23:47PM +0500, rihad wrote: > > > > Few questions: > > 1) why are you not using fastforwarding? > > 2) search_steps/searches ratio is not that good, are you using 'buckets' > > keyword in your pipe configuration? > > 3) you have net.inet.ip.fw.one_pass = 0, is it intended? > > > 1) and 3): the box does traffic accounting and shaping, so I need > one_pass=0 to do both ngtee and pipes. Still can not see any objection for not using fastforwarding, and usually ipfw ruleset can be rearranged for using dummynet & netgraph with one_pass=1. Could you show your 'ipfw show' output? (hide ip addresses if you wish but keep counters please). > 2) Hm, I'm not using "buckets", but rather > net.inet.ip.dummynet.hash_size. It's at default, 64. I've tried setting > net.inet.ip.dummynet.hash_size=65536 in sysctl.conf but somehow it was > still 64 after reboot, so I left it at 64. Should I make it 128? 256? > Does it matter that much? The load is at approx. 70-120 consumers per > pipe, so I thought 64 bucket size was enough. It depends on traffic pattern, try to increase it and watch search_steps/searches ratio (~1.001 is good enough) -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From rihad at mail.ru Wed Oct 7 10:52:58 2009 From: rihad at mail.ru (rihad) Date: Wed Oct 7 10:53:05 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091007104525.GC88982@lath.rinet.ru> References: <4AC8A76B.3050502@mail.ru> <20091007085902.GA88982@lath.rinet.ru> <4ACC5E23.8090405@mail.ru> <20091007100503.GB88982@lath.rinet.ru> <4ACC6A7B.5050808@mail.ru> <20091007104525.GC88982@lath.rinet.ru> Message-ID: <4ACC7308.6070301@mail.ru> Oleg Bulyzhin wrote: > On Wed, Oct 07, 2009 at 03:16:27PM +0500, rihad wrote: >> Oleg Bulyzhin wrote: >>> On Wed, Oct 07, 2009 at 02:23:47PM +0500, rihad wrote: >>> >>> Few questions: >>> 1) why are you not using fastforwarding? >>> 2) search_steps/searches ratio is not that good, are you using 'buckets' >>> keyword in your pipe configuration? >>> 3) you have net.inet.ip.fw.one_pass = 0, is it intended? >>> >> 1) and 3): the box does traffic accounting and shaping, so I need >> one_pass=0 to do both ngtee and pipes. > Still can not see any objection for not using fastforwarding, and usually > ipfw ruleset can be rearranged for using dummynet & netgraph with one_pass=1. You probably have some special sources of documentation ;-) According to man ipfw, both "netgraph/ngtee" and "pipe" decide the fate of the packet unless one_pass=0. Or do you mean sprinkling smart skiptos here and there? ;-) > Could you show your 'ipfw show' output? (hide ip addresses if you wish but > keep counters please). > Here it is, in its whole glory: 00100 10434423 1484891105 allow ip from any to any via lo0 00200 2 14 deny ip from any to 127.0.0.0/8 00300 1 4 deny ip from 127.0.0.0/8 to any 01000 3300039938 327603104711 allow ip from any to any in 01010 26214900 421138433 allow ip from me to any out 01020 5453857 46806278 allow icmp from any to any out 01030 3268289053 327224694165 ngtee 1 ip from any to any out 01040 18681181 1089636054 skipto 1100 ip from table(127) to any out recv bce0 xmit bce1 01060 777488848 76743392754 pipe tablearg ip from any to table(0) out recv bce0 xmit bce1 01070 776831109 76682499457 allow ip from any to table(0) out recv bce0 xmit bce1 01100 13102697 808411842 pipe tablearg ip from any to table(2) out 65535 662648946 66711487830 allow ip from any to any table(127) is static in nature and is under 100 entries. table(0) and table(2) have the same IP clients' addresses but different pipe IDs. >> 2) Hm, I'm not using "buckets", but rather >> net.inet.ip.dummynet.hash_size. It's at default, 64. I've tried setting >> net.inet.ip.dummynet.hash_size=65536 in sysctl.conf but somehow it was >> still 64 after reboot, so I left it at 64. Should I make it 128? 256? >> Does it matter that much? The load is at approx. 70-120 consumers per >> pipe, so I thought 64 bucket size was enough. > It depends on traffic pattern, try to increase it and watch > search_steps/searches ratio (~1.001 is good enough) > Hm, thanks, I'll try that. From rihad at mail.ru Wed Oct 7 11:23:39 2009 From: rihad at mail.ru (rihad) Date: Wed Oct 7 11:23:47 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACC7308.6070301@mail.ru> References: <4AC8A76B.3050502@mail.ru> <20091007085902.GA88982@lath.rinet.ru> <4ACC5E23.8090405@mail.ru> <20091007100503.GB88982@lath.rinet.ru> <4ACC6A7B.5050808@mail.ru> <20091007104525.GC88982@lath.rinet.ru> <4ACC7308.6070301@mail.ru> Message-ID: <4ACC7A38.50809@mail.ru> rihad wrote: > Oleg Bulyzhin wrote: >> On Wed, Oct 07, 2009 at 03:16:27PM +0500, rihad wrote: >>> Oleg Bulyzhin wrote: >>>> On Wed, Oct 07, 2009 at 02:23:47PM +0500, rihad wrote: >>>> >>>> Few questions: >>>> 1) why are you not using fastforwarding? >>>> 2) search_steps/searches ratio is not that good, are you using >>>> 'buckets' >>>> keyword in your pipe configuration? >>>> 3) you have net.inet.ip.fw.one_pass = 0, is it intended? >>>> >>> 1) and 3): the box does traffic accounting and shaping, so I need >>> one_pass=0 to do both ngtee and pipes. >> Still can not see any objection for not using fastforwarding, and usually >> ipfw ruleset can be rearranged for using dummynet & netgraph with >> one_pass=1. > > You probably have some special sources of documentation ;-) According to > man ipfw, both "netgraph/ngtee" and "pipe" decide the fate of the packet > unless one_pass=0. Or do you mean sprinkling smart skiptos here and > there? ;-) > >> Could you show your 'ipfw show' output? (hide ip addresses if you wish >> but >> keep counters please). >> > Here it is, in its whole glory: > > 00100 10434423 1484891105 allow ip from any to any via lo0 > 00200 2 14 deny ip from any to 127.0.0.0/8 > 00300 1 4 deny ip from 127.0.0.0/8 to any > 01000 3300039938 327603104711 allow ip from any to any in > 01010 26214900 421138433 allow ip from me to any out > 01020 5453857 46806278 allow icmp from any to any out > 01030 3268289053 327224694165 ngtee 1 ip from any to any out > 01040 18681181 1089636054 skipto 1100 ip from table(127) to any out > recv bce0 xmit bce1 > 01060 777488848 76743392754 pipe tablearg ip from any to table(0) out > recv bce0 xmit bce1 > 01070 776831109 76682499457 allow ip from any to table(0) out recv > bce0 xmit bce1 > 01100 13102697 808411842 pipe tablearg ip from any to table(2) out > 65535 662648946 66711487830 allow ip from any to any > > table(127) is static in nature and is under 100 entries. > table(0) and table(2) have the same IP clients' addresses but different > pipe IDs. > >>> 2) Hm, I'm not using "buckets", but rather >>> net.inet.ip.dummynet.hash_size. It's at default, 64. I've tried >>> setting net.inet.ip.dummynet.hash_size=65536 in sysctl.conf but >>> somehow it was still 64 after reboot, so I left it at 64. Should I >>> make it 128? 256? Does it matter that much? The load is at approx. >>> 70-120 consumers per pipe, so I thought 64 bucket size was enough. >> It depends on traffic pattern, try to increase it and watch >> search_steps/searches ratio (~1.001 is good enough) >> After reconfiguring all pipes with hash_size=256 (4 times as much as before), the ratio has started decreasing slowly. Run by me every 5-100 seconds: [rihad@billing ~]$ echo "$(sysctl -n net.inet.ip.dummynet.search_steps)/$(sysctl -n net.inet.ip.dummynet.searches)" | bc -l 1.10639566354978963640 [rihad@billing ~]$ echo "$(sysctl -n net.inet.ip.dummynet.search_steps)/$(sysctl -n net.inet.ip.dummynet.searches)" | bc -l 1.10638988711274017516 [rihad@billing ~]$ echo "$(sysctl -n net.inet.ip.dummynet.search_steps)/$(sysctl -n net.inet.ip.dummynet.searches)" | bc -l 1.10637649664889937145 [rihad@billing ~]$ echo "$(sysctl -n net.inet.ip.dummynet.search_steps)/$(sysctl -n net.inet.ip.dummynet.searches)" | bc -l 1.10636898392044547569 [rihad@billing ~]$ echo "$(sysctl -n net.inet.ip.dummynet.search_steps)/$(sysctl -n net.inet.ip.dummynet.searches)" | bc -l 1.10634798328730542254 [rihad@billing ~]$ echo "$(sysctl -n net.inet.ip.dummynet.search_steps)/$(sysctl -n net.inet.ip.dummynet.searches)" | bc -l 1.10608591323771604268 [rihad@billing ~]$ echo "$(sysctl -n net.inet.ip.dummynet.search_steps)/$(sysctl -n net.inet.ip.dummynet.searches)" | bc -l 1.10600110020578292697 but the number of drops is still there. Run every minute: Wed Oct 7 11:00:44 UTC 2009 34630 output packets dropped due to no bufs, etc. Wed Oct 7 11:01:44 UTC 2009 34630 output packets dropped due to no bufs, etc. Wed Oct 7 11:02:44 UTC 2009 34729 output packets dropped due to no bufs, etc. Wed Oct 7 11:03:44 UTC 2009 34729 output packets dropped due to no bufs, etc. Wed Oct 7 11:04:44 UTC 2009 34861 output packets dropped due to no bufs, etc. Wed Oct 7 11:05:44 UTC 2009 34932 output packets dropped due to no bufs, etc. Wed Oct 7 11:06:44 UTC 2009 35499 output packets dropped due to no bufs, etc. Wed Oct 7 11:07:45 UTC 2009 35780 output packets dropped due to no bufs, etc. Wed Oct 7 11:08:45 UTC 2009 35841 output packets dropped due to no bufs, etc. Wed Oct 7 11:09:45 UTC 2009 36348 output packets dropped due to no bufs, etc. Wed Oct 7 11:10:45 UTC 2009 36568 output packets dropped due to no bufs, etc. Wed Oct 7 11:11:45 UTC 2009 36673 output packets dropped due to no bufs, etc. Wed Oct 7 11:12:45 UTC 2009 36673 output packets dropped due to no bufs, etc. Wed Oct 7 11:13:46 UTC 2009 36673 output packets dropped due to no bufs, etc. Wed Oct 7 11:14:46 UTC 2009 36673 output packets dropped due to no bufs, etc. Wed Oct 7 11:15:46 UTC 2009 36673 output packets dropped due to no bufs, etc. Wed Oct 7 11:16:46 UTC 2009 36849 output packets dropped due to no bufs, etc. Wed Oct 7 11:17:46 UTC 2009 37234 output packets dropped due to no bufs, etc. Wed Oct 7 11:18:46 UTC 2009 37949 output packets dropped due to no bufs, etc. Wed Oct 7 11:19:47 UTC 2009 38043 output packets dropped due to no bufs, etc. Wed Oct 7 11:20:47 UTC 2009 38549 output packets dropped due to no bufs, etc. 2200-2350 users online (ipfw table load). I'll wait and see if the drop rate approaches 500-1000 per second as the number of online users comes close to 3-4K. net.isr.direct=0 From barney_cordoba at yahoo.com Wed Oct 7 11:29:23 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Wed Oct 7 11:29:29 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACC7A38.50809@mail.ru> Message-ID: <397638.11040.qm@web63902.mail.re1.yahoo.com> --- On Wed, 10/7/09, rihad wrote: > From: rihad > Subject: Re: dummynet dropping too many packets > To: "Oleg Bulyzhin" > Cc: freebsd-net@freebsd.org > Date: Wednesday, October 7, 2009, 7:23 AM > rihad wrote: > > Oleg Bulyzhin wrote: > >> On Wed, Oct 07, 2009 at 03:16:27PM +0500, rihad > wrote: > >>> Oleg Bulyzhin wrote: > >>>> On Wed, Oct 07, 2009 at 02:23:47PM +0500, > rihad wrote: > >>>> > >>>> Few questions: > >>>> 1) why are you not using fastforwarding? > >>>> 2) search_steps/searches ratio is not that > good, are you using 'buckets' > >>>>? ? keyword in your pipe > configuration? > >>>> 3) you have net.inet.ip.fw.one_pass = 0, > is it intended? > >>>> > >>> 1) and 3): the box does traffic accounting and > shaping, so I need one_pass=0 to do both ngtee and pipes. > >> Still can not see any objection for not using > fastforwarding, and usually > >> ipfw ruleset can be rearranged for using dummynet > & netgraph with one_pass=1. > > > > You probably have some special sources of > documentation ;-) According to man ipfw, both > "netgraph/ngtee" and "pipe" decide the fate of the packet > unless one_pass=0. Or do you mean sprinkling smart skiptos > here and there? ;-) > > > >> Could you show your 'ipfw show' output? (hide ip > addresses if you wish but > >> keep counters please). > >> > > Here it is, in its whole glory: > > > > > 00100???10434423???1484891105 > allow ip from any to any via lo0 > > 00200? ? ? ? ? 2? ? > ? ? ???14 deny ip from any to > 127.0.0.0/8 > > 00300? ? ? ? ? 1? ? > ? ? ? ? 4 deny ip from 127.0.0.0/8 to > any > > 01000 3300039938 327603104711 allow ip from any to any > in > > 01010???26214900? ? 421138433 > allow ip from me to any out > > 01020? ? 5453857? > ???46806278 allow icmp from any to any out > > 01030 3268289053 327224694165 ngtee 1 ip from any to > any out > > > 01040???18681181???1089636054 > skipto 1100 ip from table(127) to any out recv bce0 xmit > bce1 > > 01060? 777488848? 76743392754 pipe tablearg > ip from any to table(0) out recv bce0 xmit bce1 > > 01070? 776831109? 76682499457 allow ip from > any to table(0) out recv bce0 xmit bce1 > > 01100???13102697? ? 808411842 > pipe tablearg ip from any to table(2) out > > 65535? 662648946? 66711487830 allow ip from > any to any > > > > table(127) is static in nature and is under 100 > entries. > > table(0) and table(2) have the same IP clients' > addresses but different pipe IDs. > > > >>> 2) Hm, I'm not using "buckets", but rather > net.inet.ip.dummynet.hash_size. It's at default, 64. I've > tried setting net.inet.ip.dummynet.hash_size=65536 in > sysctl.conf but somehow it was still 64 after reboot, so I > left it at 64. Should I make it 128? 256? Does it matter > that much? The load is at approx. 70-120 consumers per pipe, > so I thought 64 bucket size was enough. > >> It depends on traffic pattern, try to increase it > and watch > >> search_steps/searches ratio (~1.001 is good > enough) > >> > After reconfiguring all pipes with hash_size=256 (4 times > as much as before), the ratio has started decreasing slowly. > Run by me every 5-100 seconds: > [rihad@billing ~]$ echo "$(sysctl -n > net.inet.ip.dummynet.search_steps)/$(sysctl -n > net.inet.ip.dummynet.searches)" | bc -l > 1.10639566354978963640 > [rihad@billing ~]$ echo "$(sysctl -n > net.inet.ip.dummynet.search_steps)/$(sysctl -n > net.inet.ip.dummynet.searches)" | bc -l > 1.10638988711274017516 > [rihad@billing ~]$ echo "$(sysctl -n > net.inet.ip.dummynet.search_steps)/$(sysctl -n > net.inet.ip.dummynet.searches)" | bc -l > 1.10637649664889937145 > [rihad@billing ~]$ echo "$(sysctl -n > net.inet.ip.dummynet.search_steps)/$(sysctl -n > net.inet.ip.dummynet.searches)" | bc -l > 1.10636898392044547569 > [rihad@billing ~]$ echo "$(sysctl -n > net.inet.ip.dummynet.search_steps)/$(sysctl -n > net.inet.ip.dummynet.searches)" | bc -l > 1.10634798328730542254 > [rihad@billing ~]$ echo "$(sysctl -n > net.inet.ip.dummynet.search_steps)/$(sysctl -n > net.inet.ip.dummynet.searches)" | bc -l > 1.10608591323771604268 > [rihad@billing ~]$ echo "$(sysctl -n > net.inet.ip.dummynet.search_steps)/$(sysctl -n > net.inet.ip.dummynet.searches)" | bc -l > 1.10600110020578292697 > > > > but the number of drops is still there. Run every minute: > Wed Oct? 7 11:00:44 UTC 2009? ? 34630 output > packets dropped due to no bufs, etc. > Wed Oct? 7 11:01:44 UTC 2009? ? 34630 output > packets dropped due to no bufs, etc. > Wed Oct? 7 11:02:44 UTC 2009? ? 34729 output > packets dropped due to no bufs, etc. > Wed Oct? 7 11:03:44 UTC 2009? ? 34729 output > packets dropped due to no bufs, etc. > Wed Oct? 7 11:04:44 UTC 2009? ? 34861 output > packets dropped due to no bufs, etc. > Wed Oct? 7 11:05:44 UTC 2009? ? 34932 output > packets dropped due to no bufs, etc. > Wed Oct? 7 11:06:44 UTC 2009? ? 35499 output > packets dropped due to no bufs, etc. > Wed Oct? 7 11:07:45 UTC 2009? ? 35780 output > packets dropped due to no bufs, etc. > Wed Oct? 7 11:08:45 UTC 2009? ? 35841 output > packets dropped due to no bufs, etc. > Wed Oct? 7 11:09:45 UTC 2009? ? 36348 output > packets dropped due to no bufs, etc. > Wed Oct? 7 11:10:45 UTC 2009? ? 36568 output > packets dropped due to no bufs, etc. > Wed Oct? 7 11:11:45 UTC 2009? ? 36673 output > packets dropped due to no bufs, etc. > Wed Oct? 7 11:12:45 UTC 2009? ? 36673 output > packets dropped due to no bufs, etc. > Wed Oct? 7 11:13:46 UTC 2009? ? 36673 output > packets dropped due to no bufs, etc. > Wed Oct? 7 11:14:46 UTC 2009? ? 36673 output > packets dropped due to no bufs, etc. > Wed Oct? 7 11:15:46 UTC 2009? ? 36673 output > packets dropped due to no bufs, etc. > Wed Oct? 7 11:16:46 UTC 2009? ? 36849 output > packets dropped due to no bufs, etc. > Wed Oct? 7 11:17:46 UTC 2009? ? 37234 output > packets dropped due to no bufs, etc. > Wed Oct? 7 11:18:46 UTC 2009? ? 37949 output > packets dropped due to no bufs, etc. > Wed Oct? 7 11:19:47 UTC 2009? ? 38043 output > packets dropped due to no bufs, etc. > Wed Oct? 7 11:20:47 UTC 2009? ? 38549 output > packets dropped due to no bufs, etc. > > 2200-2350 users online (ipfw table load). I'll wait and see > if the drop rate approaches 500-1000 per second as the > number of online users comes close to 3-4K. > > net.isr.direct=0 Its frightening to me that someone is managing such a large network with dummynet. Talk about stealing your customer's money. BC From rihad at mail.ru Wed Oct 7 11:38:39 2009 From: rihad at mail.ru (rihad) Date: Wed Oct 7 11:38:47 2009 Subject: dummynet dropping too many packets In-Reply-To: <397638.11040.qm@web63902.mail.re1.yahoo.com> References: <397638.11040.qm@web63902.mail.re1.yahoo.com> Message-ID: <4ACC7DBD.8070007@mail.ru> > Its frightening to me that someone is managing such a large network > with dummynet. Talk about stealing your customer's money. > We have no customers - we're a charity ISP. Any alternatives? ALTQ? From oleg at FreeBSD.org Wed Oct 7 11:54:26 2009 From: oleg at FreeBSD.org (Oleg Bulyzhin) Date: Wed Oct 7 11:54:33 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACC7308.6070301@mail.ru> References: <4AC8A76B.3050502@mail.ru> <20091007085902.GA88982@lath.rinet.ru> <4ACC5E23.8090405@mail.ru> <20091007100503.GB88982@lath.rinet.ru> <4ACC6A7B.5050808@mail.ru> <20091007104525.GC88982@lath.rinet.ru> <4ACC7308.6070301@mail.ru> Message-ID: <20091007115425.GD88982@lath.rinet.ru> On Wed, Oct 07, 2009 at 03:52:56PM +0500, rihad wrote: > You probably have some special sources of documentation ;-) According to > man ipfw, both "netgraph/ngtee" and "pipe" decide the fate of the packet > unless one_pass=0. Or do you mean sprinkling smart skiptos here and > there? ;-) you can 1) use ng_ether & ng_netflow. (so no need in 'ngtee' rule). 2) use 'tee' rule with ng_ksocket & ng_netflow > > > Could you show your 'ipfw show' output? (hide ip addresses if you wish but > > keep counters please). > > > Here it is, in its whole glory: > > 00100 10434423 1484891105 allow ip from any to any via lo0 > 00200 2 14 deny ip from any to 127.0.0.0/8 > 00300 1 4 deny ip from 127.0.0.0/8 to any > 01000 3300039938 327603104711 allow ip from any to any in > 01010 26214900 421138433 allow ip from me to any out > 01020 5453857 46806278 allow icmp from any to any out > 01030 3268289053 327224694165 ngtee 1 ip from any to any out > 01040 18681181 1089636054 skipto 1100 ip from table(127) to any out > recv bce0 xmit bce1 > 01060 777488848 76743392754 pipe tablearg ip from any to table(0) out > recv bce0 xmit bce1 > 01070 776831109 76682499457 allow ip from any to table(0) out recv > bce0 xmit bce1 > 01100 13102697 808411842 pipe tablearg ip from any to table(2) out > 65535 662648946 66711487830 allow ip from any to any I guess this one would be better(faster): 00050 allow ip from any to any in 00100 allow ip from any to any via lo0 01010 allow ip from me to any 01020 allow icmp from any to any 01030 ngtee 1 ip from any to any 01035 skipto 1040 ip from any to any recv bce0 xmit bce1 01036 allow ip from any to any 01040 skipto 1100 ip from table(127) to any 01060 pipe tablearg ip from any to table(0) 01070 allow ip from any to any 01100 pipe tablearg ip from any to table(2) 65535 allow ip from any to any P.S. have you tried net.inet.ip.fastforwarding=1? -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From rihad at mail.ru Wed Oct 7 12:10:33 2009 From: rihad at mail.ru (rihad) Date: Wed Oct 7 12:10:39 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091007115425.GD88982@lath.rinet.ru> References: <4AC8A76B.3050502@mail.ru> <20091007085902.GA88982@lath.rinet.ru> <4ACC5E23.8090405@mail.ru> <20091007100503.GB88982@lath.rinet.ru> <4ACC6A7B.5050808@mail.ru> <20091007104525.GC88982@lath.rinet.ru> <4ACC7308.6070301@mail.ru> <20091007115425.GD88982@lath.rinet.ru> Message-ID: <4ACC8535.70403@mail.ru> Oleg Bulyzhin wrote: > On Wed, Oct 07, 2009 at 03:52:56PM +0500, rihad wrote: > >> You probably have some special sources of documentation ;-) According to >> man ipfw, both "netgraph/ngtee" and "pipe" decide the fate of the packet >> unless one_pass=0. Or do you mean sprinkling smart skiptos here and >> there? ;-) > > you can > 1) use ng_ether & ng_netflow. (so no need in 'ngtee' rule). > 2) use 'tee' rule with ng_ksocket & ng_netflow > Thanks, I'll see into that if fast-forwarding doesn't help. >>> Could you show your 'ipfw show' output? (hide ip addresses if you wish but >>> keep counters please). >>> > >> Here it is, in its whole glory: >> >> 00100 10434423 1484891105 allow ip from any to any via lo0 >> 00200 2 14 deny ip from any to 127.0.0.0/8 >> 00300 1 4 deny ip from 127.0.0.0/8 to any >> 01000 3300039938 327603104711 allow ip from any to any in >> 01010 26214900 421138433 allow ip from me to any out >> 01020 5453857 46806278 allow icmp from any to any out >> 01030 3268289053 327224694165 ngtee 1 ip from any to any out >> 01040 18681181 1089636054 skipto 1100 ip from table(127) to any out >> recv bce0 xmit bce1 >> 01060 777488848 76743392754 pipe tablearg ip from any to table(0) out >> recv bce0 xmit bce1 >> 01070 776831109 76682499457 allow ip from any to table(0) out recv >> bce0 xmit bce1 >> 01100 13102697 808411842 pipe tablearg ip from any to table(2) out >> 65535 662648946 66711487830 allow ip from any to any > > I guess this one would be better(faster): > > 00050 allow ip from any to any in > 00100 allow ip from any to any via lo0 > 01010 allow ip from me to any > 01020 allow icmp from any to any > 01030 ngtee 1 ip from any to any > 01035 skipto 1040 ip from any to any recv bce0 xmit bce1 > 01036 allow ip from any to any > 01040 skipto 1100 ip from table(127) to any > 01060 pipe tablearg ip from any to table(0) > 01070 allow ip from any to any > 01100 pipe tablearg ip from any to table(2) > 65535 allow ip from any to any > Phew, were "out" that bad? I left them in as commentary. And the localhost anti-spoof check isn't such a bad security ring to get rid of in the name of performance ;-) Ok, got you, I'll take a note of it, thanks. > P.S. have you tried net.inet.ip.fastforwarding=1? > man 4 inet: IPCTL_FASTFORWARDING (ip.fastforwarding) Boolean: enable/disable the use of fast IP forwarding code. Defaults to off. When fast IP forwarding is enabled, IP packets are for- warded directly to the appropriate network inter- face with direct processing to completion, which greatly improves the throughput. All packets for local IP addresses, non-unicast, or with IP options are handled by the normal IP input processing path. All features of the normal (slow) IP forwarding path are supported including firewall (through pfil(9) hooks) checking, except ipsec(4) tunnel brokering. The IP fastforwarding path does not generate ICMP redirect or source quench messages. I'm afraid a bit that it will lock up the live remote system. Is it a drop in replacement given my ipfw rules? Why isn't it enabled by default? From rihad at mail.ru Wed Oct 7 12:13:08 2009 From: rihad at mail.ru (rihad) Date: Wed Oct 7 12:13:14 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACC8535.70403@mail.ru> References: <4AC8A76B.3050502@mail.ru> <20091007085902.GA88982@lath.rinet.ru> <4ACC5E23.8090405@mail.ru> <20091007100503.GB88982@lath.rinet.ru> <4ACC6A7B.5050808@mail.ru> <20091007104525.GC88982@lath.rinet.ru> <4ACC7308.6070301@mail.ru> <20091007115425.GD88982@lath.rinet.ru> <4ACC8535.70403@mail.ru> Message-ID: <4ACC85D1.5070908@mail.ru> > Why isn't it enabled by default? > Answering myself: probably because of this: The IP fastforwarding path does not generate ICMP redirect or source quench messages. From rwatson at FreeBSD.org Wed Oct 7 12:21:44 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Oct 7 12:21:51 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACC65A0.7030900@mail.ru> References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> <4ACC5563.602@mail.ru> <4ACC56A6.1030808@mail.ru> <4ACC5DEC.1010006@mail.ru> <4ACC65A0.7030900@mail.ru> Message-ID: On Wed, 7 Oct 2009, rihad wrote: > Robert Watson wrote: >> >> On Wed, 7 Oct 2009, rihad wrote: >> >>>> snapshot of the top -SH output in the steady state? Let top run for a >>>> few minutes and then copy/paste the first 10-20 lines into an e-mail. >>>> >>> Sure. Mind you: now there's only 1800 entries in each of the two ipfw >>> tables, so any drops have stopped. But it only takes another 200-300 >>> entries to start dropping. >> >> Could you do the same in the net.isr.direct=1 configuration so we can >> compare? > > net.isr.direct=1: So it seems that CPU exhaustion is likely not the source of drops -- what I was looking for in both configurations were signs that any individual thread was approaching 80% utilization, which in a peak load situation might mean it hitting 100% and therefore leading to packet loss for that reason. The statistic you're monitoring has a couple of interpretations, but the most likely interpretation is overfilling the output queue on the network interface you're transmitting on. In turn there are various possible reasons for this happening, but the two most common would be: (1) Average load is exceeding the transmit capacity of the driver/hardware pipeline -- the pipe is just too small. (2) Peak capacity (burstiness) is exceeding the transmit capacity of the driver/hardware pipeline. The questions that Luigi and others have been asking about your dummynet configuration are to some extent oriented around determining whether the burstiness introduced by dummynet could be responsible for that. Suggestions like increasing timer resolution are intended to spread out the injection of packets by dummynet to attempt to reduce the peaks of burstiness that occur when multiple queues inject packets in a burst that exceeds the queue depth supported by combined hardware descriptor rings and software transmit queue. The two solutions, then are (a) to increase the timer resolution significantly so that packets are injected in smaller bursts and (b) increase the queue capacities. The hardware queue limits likely can't be raised w/o new hardware, but the ifnet transmit queue sizes can be increased. Timer resolution going up is almost certainly not a bad idea in your configuration, although does require a reboot as you have observed. On a side note: one other possible interpretation of that statistic is that you're seeing fragmentation problems. Usually in forwarding scenarios this is unlikely. However, it wouldn't hurt to make sure you have LRO turned off on the network interfaces you're using, assuming it's supported by the driver. Robert N M Watson Computer Laboratory University of Cambridge > > last pid: 92152; load averages: 0.99, 1.18, 1.15 > up 1+01:42:28 14:53:09 > 162 processes: 9 running, 136 sleeping, 17 waiting > CPU: 2.1% user, 0.0% nice, 5.4% system, 7.0% interrupt, 85.5% idle > Mem: 1693M Active, 1429M Inact, 447M Wired, 197M Cache, 214M Buf, 170M Free > Swap: 2048M Total, 12K Used, 2048M Free > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 12 root 171 ki31 0K 16K CPU6 6 24.3H 100.00% idle: cpu6 > 13 root 171 ki31 0K 16K CPU5 5 23.8H 95.95% idle: cpu5 > 14 root 171 ki31 0K 16K CPU4 4 23.4H 93.12% idle: cpu4 > 16 root 171 ki31 0K 16K CPU2 2 23.0H 90.19% idle: cpu2 > 11 root 171 ki31 0K 16K CPU7 7 24.2H 87.26% idle: cpu7 > 15 root 171 ki31 0K 16K CPU3 3 22.8H 86.18% idle: cpu3 > 18 root 171 ki31 0K 16K RUN 0 20.6H 84.96% idle: cpu0 > 17 root 171 ki31 0K 16K CPU1 1 933:23 47.85% idle: cpu1 > 29 root -68 - 0K 16K WAIT 1 522:02 46.88% irq256: bce0 > 465 root -68 - 0K 16K - 7 55:15 12.65% dummynet > 31 root -68 - 0K 16K WAIT 2 57:29 4.74% irq257: bce1 > 21 root -44 - 0K 16K WAIT 0 34:55 4.64% swi1: net > 19 root -32 - 0K 16K WAIT 4 51:41 3.96% swi4: clock > sio > 30 root -64 - 0K 16K WAIT 6 5:43 0.73% irq16: mfi0 > > > Almost 2000 entries in the table, traffic load= 420-430 mbps, drops haven't > yet started. > > Previous net.isr.direct=0: >> >>> >>> 155 processes: 10 running, 129 sleeping, 16 waiting >>> CPU: 2.4% user, 0.0% nice, 2.0% system, 9.3% interrupt, 86.2% idle >>> Mem: 1691M Active, 1491M Inact, 454M Wired, 130M Cache, 214M Buf, 170M >>> Free >>> Swap: 2048M Total, 12K Used, 2048M Free >>> >>> PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND >>> 15 root 171 ki31 0K 16K CPU3 3 22.4H 97.85% idle: cpu3 >>> 14 root 171 ki31 0K 16K CPU4 4 23.0H 96.29% idle: cpu4 >>> 12 root 171 ki31 0K 16K CPU6 6 23.8H 94.58% idle: cpu6 >>> 16 root 171 ki31 0K 16K CPU2 2 22.5H 90.72% idle: cpu2 >>> 13 root 171 ki31 0K 16K CPU5 5 23.4H 90.58% idle: cpu5 >>> 18 root 171 ki31 0K 16K RUN 0 20.3H 85.60% idle: cpu0 >>> 17 root 171 ki31 0K 16K CPU1 1 910:03 78.37% idle: cpu1 >>> 11 root 171 ki31 0K 16K CPU7 7 23.8H 65.62% idle: cpu7 >>> 21 root -44 - 0K 16K CPU7 7 19:03 48.34% swi1: net >>> 29 root -68 - 0K 16K WAIT 1 515:49 19.63% irq256: bce0 >>> 31 root -68 - 0K 16K WAIT 2 56:05 5.52% irq257: bce1 >>> 19 root -32 - 0K 16K WAIT 5 50:05 3.86% swi4: clock >>> sio >>> 983 flowtools 44 0 12112K 6440K select 0 13:20 0.15% flow-capture >>> 465 root -68 - 0K 16K - 3 51:19 0.00% dummynet >>> 3 root -8 - 0K 16K - 1 7:41 0.00% g_up >>> 4 root -8 - 0K 16K - 2 7:14 0.00% g_down >>> 30 root -64 - 0K 16K WAIT 6 5:30 0.00% irq16: mfi0 >>> >>> >> >> > > From rihad at mail.ru Wed Oct 7 12:29:05 2009 From: rihad at mail.ru (rihad) Date: Wed Oct 7 12:29:12 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091007115425.GD88982@lath.rinet.ru> References: <4AC8A76B.3050502@mail.ru> <20091007085902.GA88982@lath.rinet.ru> <4ACC5E23.8090405@mail.ru> <20091007100503.GB88982@lath.rinet.ru> <4ACC6A7B.5050808@mail.ru> <20091007104525.GC88982@lath.rinet.ru> <4ACC7308.6070301@mail.ru> <20091007115425.GD88982@lath.rinet.ru> Message-ID: <4ACC898C.8000807@mail.ru> Oleg Bulyzhin wrote: > On Wed, Oct 07, 2009 at 03:52:56PM +0500, rihad wrote: > > P.S. have you tried net.inet.ip.fastforwarding=1? > Yup, it didn't help at all. Reverting it back to 0 for now. From rwatson at freebsd.org Wed Oct 7 12:33:28 2009 From: rwatson at freebsd.org (Robert N. M. Watson) Date: Wed Oct 7 12:33:35 2009 Subject: panic in soabort In-Reply-To: References: Message-ID: <6693EC21-203E-4E3C-B93B-65C70E8BF128@freebsd.org> On 1 Oct 2009, at 12:24, pluknet wrote: >>> If you run into this again, let me know. Also, are you using >>> accept filters >>> on the box? >>> >> >> Got it again (this time on 6.4-p5). > > P.S. > It's funny to say: I got it on two boxes nearly simultaneously. > Both from proftpd. See also my first mail (the same). I'll take a further look at this today sometime, but it is my belief (FYI) that the new socket life cycle in 7.x closes many possible races along these lines. As such, while we can try to track down and resolve this, you might find it simply "goes away" if you move to 7. If you do see it in 7 then I would be especially interested :-). There are two sockets involved here, and I'd like to get some debugging information on both. First, it looks like close() is being called on a listen socket -- could something be killing the proftpd instance on both your boxes at about the same time, perhaps due to shutdown or some admin event? For both sockets, the one passed to soclose and the one passed to soabort, could you provide structure dumps of: (1) *so (2) *(struct inpcb *)(so->so_pcb) (3) Depending on whether INP_TIMEWAIT is set in the inp_flags field, either *(struct tcpcb)((struct inpcb *)(so->so_pcb)->inp_ppcb) or the same cast but struct tcptw if it is in timewait. It seems likely we're dealing with a race condition in which close() on a listen socket aborts a pending connection at the same time as a network event, such as a received reset/fin/etc. Robert > >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 2; apic id = 02 >> fault virtual address = 0x104 >> fault code = supervisor read, page not present >> instruction pointer = 0x20:0xc06a3425 >> stack pointer = 0x28:0xef764bb0 >> frame pointer = 0x28:0xef764bbc >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = resume, IOPL = 0 >> current process = 74303 (proftpd) >> >> db> bt 74303 >> Tracing pid 74303 tid 101039 td 0xcaa08820 >> _mtx_lock_sleep(ccd50768,caa08820,0,0,0) at _mtx_lock_sleep+0x9d >> soabort(ccd506f4) at soabort+0x82 >> soclose(d1aa8b20) at soclose+0x21a >> soo_close(c9f50a20,caa08820) at soo_close+0x63 >> fdrop_locked(c9f50a20,caa08820,caf78a00,ef764ca8,c06875f3,...) at >> fdrop_locked+0xd0 >> fdrop(c9f50a20,caa08820,caa08820,ef764c64,c0689055,...) at fdrop+0x41 >> closef(c9f50a20,caa08820,0,ef764d38,cad8f648,...) at closef+0x42f >> kern_close(caa08820,a,ef764d30,c08e1d4b,caa08820,...) at kern_close >> +0x20d >> close(caa08820,ef764d04) at close+0x10 >> syscall(bfbf003b,3b,bfbf003b,8150034,811a434,...) at syscall+0x2bf >> Xint0x80_syscall() at Xint0x80_syscall+0x1f >> --- syscall (6, FreeBSD ELF32, close), eip = 0x2832230f, esp = >> 0xbfbfe6bc, ebp = 0xbfbfe6d8 --- >> db> show proc 74303 >> Process 74303 (proftpd) at 0xcad8f648: >> state: NORMAL >> uid: 36830 gids: 36830 >> parent: pid 95478 at 0xc8e60000 >> ABI: FreeBSD ELF32 >> arguments: proftpd: fatich_1 - 93.118.217.18: IDLE >> threads: 1 >> 101039 Run CPU 2 proftpd >> >> (gdb) list *(soabort+0x82) >> 0xc06ea2a6 is in soabort (/usr/src/sys/kern/uipc_socket.c:510). >> 505 int error; >> 506 >> 507 error = (*so->so_proto->pr_usrreqs->pru_abort)(so); >> 508 if (error) { >> 509 ACCEPT_LOCK(); >> 510 SOCK_LOCK(so); >> 511 sotryfree(so); /* note: does not decrement >> the ref count */ >> 512 return error; >> 513 } >> 514 return (0); >> >> -- >> wbr, >> pluknet >> > > > > -- > wbr, > pluknet From rihad at mail.ru Wed Oct 7 12:42:53 2009 From: rihad at mail.ru (rihad) Date: Wed Oct 7 12:43:00 2009 Subject: dummynet dropping too many packets In-Reply-To: References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> <4ACC5563.602@mail.ru> <4ACC56A6.1030808@mail.ru> <4ACC5DEC.1010006@mail.ru> <4ACC65A0.7030900@mail.ru> Message-ID: <4ACC8CC8.8050403@mail.ru> Robert Watson wrote: > Suggestions like increasing timer resolution are intended to spread out > the injection of packets by dummynet to attempt to reduce the peaks of > burstiness that occur when multiple queues inject packets in a burst > that exceeds the queue depth supported by combined hardware descriptor > rings and software transmit queue. > Raising HZ from 1000 to 2000 has helped. There are now 200-300 global drops/s, as opposed to 300-1000 with HZ=1000. Or maybe net.isr.direct from 1 to 0 help. Or maybe hash_size from 64 to 256. Or maybe... > The two solutions, then are (a) to increase the timer resolution > significantly so that packets are injected in smaller bursts But isn't that bad that it can actually become worse? From /sys/conf/NOTES: # The granularity of operation is controlled by the kernel option HZ whose # default value (1000 on most architectures) means a granularity of 1ms # (1s/HZ). Historically, the default was 100, but finer granularity is # required for DUMMYNET and other systems on modern hardware. There are # reasonable arguments that HZ should, in fact, be 100 still; consider, # that reducing the granularity too much might cause excessive overhead in # clock interrupt processing, potentially causing ticks to be missed and thus # actually reducing the accuracy of operation. > and (b) increase the queue capacities. The hardware queue limits likely can't > be raised w/o new hardware, but the ifnet transmit queue sizes can be > increased. Can someone please say how to increase the "ifnet transmit queue sizes"? > Timer resolution going up is almost certainly not a bad idea in your configuration, although does require a reboot as you have observed. > OK, I'll try HZ=4000, but there are some required servers like flowtools/radius/mysql/perl app that are also running. > On a side note: one other possible interpretation of that statistic is > that you're seeing fragmentation problems. Usually in forwarding > scenarios this is unlikely. However, it wouldn't hurt to make sure you > have LRO turned off on the network interfaces you're using, assuming > it's supported by the driver. > I don't think fragments are the problem. The numbers are too small ;-) $ netstat -s|fgrep fragment 5318 fragments received 147 fragments dropped (dup or out of space) 5157 fragments dropped after timeout 4088 output datagrams fragmented 8180 fragments created 0 datagrams that can't be fragmented There's no such option as LRO shown, so I guess it's off: options=1bb From dfilter at FreeBSD.ORG Wed Oct 7 13:20:04 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Wed Oct 7 13:20:12 2009 Subject: kern/127587: commit references a PR Message-ID: <200910071320.n97DK4Ca070063@freefall.freebsd.org> The following reply was made to PR kern/127587; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/127587: commit references a PR Date: Wed, 7 Oct 2009 13:12:58 +0000 (UTC) Author: stas Date: Wed Oct 7 13:12:43 2009 New Revision: 197832 URL: http://svn.freebsd.org/changeset/base/197832 Log: - Add support for new BGE chips (5761, 5784 and 57780). These chips uses new BGE_PCI_PRODID_ASICREV register to store the chip identifier and its revision. - Add new grouping macro for 7575+ chips (BGE_IS_5755_PLUS). - Add IDs for Fujitsu-branded Broadcom adapters. PR: kern/127587 Tested by: Thomas Quinot (BCM7561 A0) MFC after: 2 weeks Obtained from: OpenBSD Modified: head/sys/dev/bge/if_bge.c head/sys/dev/bge/if_bgereg.h Modified: head/sys/dev/bge/if_bge.c ============================================================================== --- head/sys/dev/bge/if_bge.c Wed Oct 7 12:38:19 2009 (r197831) +++ head/sys/dev/bge/if_bge.c Wed Oct 7 13:12:43 2009 (r197832) @@ -170,6 +170,7 @@ static const struct bge_type { { BCOM_VENDORID, BCOM_DEVICEID_BCM5720 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5721 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5722 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5723 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5750 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5750M }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5751 }, @@ -184,12 +185,21 @@ static const struct bge_type { { BCOM_VENDORID, BCOM_DEVICEID_BCM5754M }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5755 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5755M }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5761 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5761E }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5761S }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5761SE }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5764 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5780 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5780S }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5781 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5782 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5784 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5785F }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5785G }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5786 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5787 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5787F }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5787M }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5788 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5789 }, @@ -198,11 +208,19 @@ static const struct bge_type { { BCOM_VENDORID, BCOM_DEVICEID_BCM5903M }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5906 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5906M }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM57760 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM57780 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM57788 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM57790 }, { SK_VENDORID, SK_DEVICEID_ALTIMA }, { TC_VENDORID, TC_DEVICEID_3C996 }, + { FJTSU_VENDORID, FJTSU_DEVICEID_PW008GE4 }, + { FJTSU_VENDORID, FJTSU_DEVICEID_PW008GE5 }, + { FJTSU_VENDORID, FJTSU_DEVICEID_PP250450 }, + { 0, 0 } }; @@ -216,6 +234,7 @@ static const struct bge_vendor { { BCOM_VENDORID, "Broadcom" }, { SK_VENDORID, "SysKonnect" }, { TC_VENDORID, "3Com" }, + { FJTSU_VENDORID, "Fujitsu" }, { 0, NULL } }; @@ -271,12 +290,18 @@ static const struct bge_revision { { BGE_CHIPID_BCM5755_A1, "BCM5755 A1" }, { BGE_CHIPID_BCM5755_A2, "BCM5755 A2" }, { BGE_CHIPID_BCM5722_A0, "BCM5722 A0" }, + { BGE_CHIPID_BCM5761_A0, "BCM5761 A0" }, + { BGE_CHIPID_BCM5761_A1, "BCM5761 A1" }, + { BGE_CHIPID_BCM5784_A0, "BCM5784 A0" }, + { BGE_CHIPID_BCM5784_A1, "BCM5784 A1" }, /* 5754 and 5787 share the same ASIC ID */ { BGE_CHIPID_BCM5787_A0, "BCM5754/5787 A0" }, { BGE_CHIPID_BCM5787_A1, "BCM5754/5787 A1" }, { BGE_CHIPID_BCM5787_A2, "BCM5754/5787 A2" }, { BGE_CHIPID_BCM5906_A1, "BCM5906 A1" }, { BGE_CHIPID_BCM5906_A2, "BCM5906 A2" }, + { BGE_CHIPID_BCM57780_A0, "BCM57780 A0" }, + { BGE_CHIPID_BCM57780_A1, "BCM57780 A1" }, { 0, NULL } }; @@ -297,9 +322,13 @@ static const struct bge_revision bge_maj { BGE_ASICREV_BCM5780, "unknown BCM5780" }, { BGE_ASICREV_BCM5714, "unknown BCM5714" }, { BGE_ASICREV_BCM5755, "unknown BCM5755" }, + { BGE_ASICREV_BCM5761, "unknown BCM5761" }, + { BGE_ASICREV_BCM5784, "unknown BCM5784" }, + { BGE_ASICREV_BCM5785, "unknown BCM5785" }, /* 5754 and 5787 share the same ASIC ID */ { BGE_ASICREV_BCM5787, "unknown BCM5754/5787" }, { BGE_ASICREV_BCM5906, "unknown BCM5906" }, + { BGE_ASICREV_BCM57780, "unknown BCM57780" }, { 0, NULL } }; @@ -309,6 +338,7 @@ static const struct bge_revision bge_maj #define BGE_IS_5705_PLUS(sc) ((sc)->bge_flags & BGE_FLAG_5705_PLUS) #define BGE_IS_5714_FAMILY(sc) ((sc)->bge_flags & BGE_FLAG_5714_FAMILY) #define BGE_IS_575X_PLUS(sc) ((sc)->bge_flags & BGE_FLAG_575X_PLUS) +#define BGE_IS_5755_PLUS(sc) ((sc)->bge_flags & BGE_FLAG_5755_PLUS) const struct bge_revision * bge_lookup_rev(uint32_t); const struct bge_vendor * bge_lookup_vendor(uint16_t); @@ -1758,8 +1788,7 @@ bge_blockinit(struct bge_softc *sc) val = BGE_WDMAMODE_ENABLE | BGE_WDMAMODE_ALL_ATTNS; /* Enable host coalescing bug fix. */ - if (sc->bge_asicrev == BGE_ASICREV_BCM5755 || - sc->bge_asicrev == BGE_ASICREV_BCM5787) + if (BGE_IS_5755_PLUS(sc)) val |= 1 << 29; /* Turn on write DMA state machine */ @@ -1768,6 +1797,12 @@ bge_blockinit(struct bge_softc *sc) /* Turn on read DMA state machine */ val = BGE_RDMAMODE_ENABLE | BGE_RDMAMODE_ALL_ATTNS; + if (sc->bge_asicrev == BGE_ASICREV_BCM5784 || + sc->bge_asicrev == BGE_ASICREV_BCM5785 || + sc->bge_asicrev == BGE_ASICREV_BCM57780) + val |= BGE_RDMAMODE_BD_SBD_CRPT_ATTN | + BGE_RDMAMODE_MBUF_RBD_CRPT_ATTN | + BGE_RDMAMODE_MBUF_SBD_CRPT_ATTN; if (sc->bge_flags & BGE_FLAG_PCIE) val |= BGE_RDMAMODE_FIFO_LONG_BURST; CSR_WRITE_4(sc, BGE_RDMA_MODE, val); @@ -1790,7 +1825,10 @@ bge_blockinit(struct bge_softc *sc) CSR_WRITE_4(sc, BGE_SBDC_MODE, BGE_SBDCMODE_ENABLE); /* Turn on send data completion state machine */ - CSR_WRITE_4(sc, BGE_SDC_MODE, BGE_SDCMODE_ENABLE); + val = BGE_SDCMODE_ENABLE; + if (sc->bge_asicrev == BGE_ASICREV_BCM5761) + val |= BGE_SDCMODE_CDELAY; + CSR_WRITE_4(sc, BGE_SDC_MODE, val); /* Turn on send data initiator state machine */ CSR_WRITE_4(sc, BGE_SDI_MODE, BGE_SDIMODE_ENABLE); @@ -1897,8 +1935,11 @@ bge_probe(device_t dev) const struct bge_vendor *v; uint32_t id; - id = pci_read_config(dev, BGE_PCI_MISC_CTL, 4) & - BGE_PCIMISCCTL_ASICREV; + id = pci_read_config(dev, BGE_PCI_MISC_CTL, 4) >> + BGE_PCIMISCCTL_ASICREV_SHIFT; + if (BGE_ASICREV(id) == BGE_ASICREV_USE_PRODID_REG) + id = pci_read_config(dev, + BGE_PCI_PRODID_ASICREV, 4); br = bge_lookup_rev(id); v = bge_lookup_vendor(vid); { @@ -1915,8 +1956,8 @@ bge_probe(device_t dev) br != NULL ? br->br_name : "NetXtreme Ethernet Controller"); } - snprintf(buf, 96, "%s, %sASIC rev. %#04x", model, - br != NULL ? "" : "unknown ", id >> 16); + snprintf(buf, 96, "%s, %sASIC rev. %#08x", model, + br != NULL ? "" : "unknown ", id); device_set_desc_copy(dev, buf); if (pci_get_subvendor(dev) == DELL_VENDORID) sc->bge_flags |= BGE_FLAG_NO_3LED; @@ -2411,8 +2452,11 @@ bge_attach(device_t dev) /* Save various chip information. */ sc->bge_chipid = - pci_read_config(dev, BGE_PCI_MISC_CTL, 4) & - BGE_PCIMISCCTL_ASICREV; + pci_read_config(dev, BGE_PCI_MISC_CTL, 4) >> + BGE_PCIMISCCTL_ASICREV_SHIFT; + if (BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_USE_PRODID_REG) + sc->bge_chipid = pci_read_config(dev, BGE_PCI_PRODID_ASICREV, + 4); sc->bge_asicrev = BGE_ASICREV(sc->bge_chipid); sc->bge_chiprev = BGE_CHIPREV(sc->bge_chipid); @@ -2431,6 +2475,15 @@ bge_attach(device_t dev) /* Save chipset family. */ switch (sc->bge_asicrev) { + case BGE_ASICREV_BCM5755: + case BGE_ASICREV_BCM5761: + case BGE_ASICREV_BCM5784: + case BGE_ASICREV_BCM5785: + case BGE_ASICREV_BCM5787: + case BGE_ASICREV_BCM57780: + sc->bge_flags |= BGE_FLAG_5755_PLUS | BGE_FLAG_575X_PLUS | + BGE_FLAG_5705_PLUS; + break; case BGE_ASICREV_BCM5700: case BGE_ASICREV_BCM5701: case BGE_ASICREV_BCM5703: @@ -2444,8 +2497,6 @@ bge_attach(device_t dev) /* FALLTHROUGH */ case BGE_ASICREV_BCM5750: case BGE_ASICREV_BCM5752: - case BGE_ASICREV_BCM5755: - case BGE_ASICREV_BCM5787: case BGE_ASICREV_BCM5906: sc->bge_flags |= BGE_FLAG_575X_PLUS; /* FALLTHROUGH */ @@ -2466,6 +2517,8 @@ bge_attach(device_t dev) if (BGE_IS_5705_PLUS(sc) && !(sc->bge_flags & BGE_FLAG_ADJUST_TRIM)) { if (sc->bge_asicrev == BGE_ASICREV_BCM5755 || + sc->bge_asicrev == BGE_ASICREV_BCM5761 || + sc->bge_asicrev == BGE_ASICREV_BCM5784 || sc->bge_asicrev == BGE_ASICREV_BCM5787) { if (sc->bge_chipid != BGE_CHIPID_BCM5722_A0) sc->bge_flags |= BGE_FLAG_JITTER_BUG; @@ -2873,8 +2926,7 @@ bge_reset(struct bge_softc *sc) /* Disable fastboot on controllers that support it. */ if (sc->bge_asicrev == BGE_ASICREV_BCM5752 || - sc->bge_asicrev == BGE_ASICREV_BCM5755 || - sc->bge_asicrev == BGE_ASICREV_BCM5787) { + BGE_IS_5755_PLUS(sc)) { if (bootverbose) device_printf(sc->bge_dev, "Disabling fastboot\n"); CSR_WRITE_4(sc, BGE_FASTBOOT_PC, 0x0); @@ -4689,6 +4741,8 @@ bge_sysctl_debug_info(SYSCTL_HANDLER_ARG } printf("Hardware Flags:\n"); + if (BGE_IS_5755_PLUS(sc)) + printf(" - 5755 Plus\n"); if (BGE_IS_575X_PLUS(sc)) printf(" - 575X Plus\n"); if (BGE_IS_5705_PLUS(sc)) Modified: head/sys/dev/bge/if_bgereg.h ============================================================================== --- head/sys/dev/bge/if_bgereg.h Wed Oct 7 12:38:19 2009 (r197831) +++ head/sys/dev/bge/if_bgereg.h Wed Oct 7 13:12:43 2009 (r197832) @@ -218,6 +218,7 @@ #define BGE_PCI_UNDI_TX_BD_PRODIDX_LO 0xAC #define BGE_PCI_ISR_MBX_HI 0xB0 #define BGE_PCI_ISR_MBX_LO 0xB4 +#define BGE_PCI_PRODID_ASICREV 0xBC /* PCI Misc. Host control register */ #define BGE_PCIMISCCTL_CLEAR_INTA 0x00000001 @@ -229,6 +230,7 @@ #define BGE_PCIMISCCTL_REG_WORDSWAP 0x00000040 #define BGE_PCIMISCCTL_INDIRECT_ACCESS 0x00000080 #define BGE_PCIMISCCTL_ASICREV 0xFFFF0000 +#define BGE_PCIMISCCTL_ASICREV_SHIFT 16 #define BGE_HIF_SWAP_OPTIONS (BGE_PCIMISCCTL_ENDIAN_WORDSWAP) #if BYTE_ORDER == LITTLE_ENDIAN @@ -245,66 +247,72 @@ (BGE_HIF_SWAP_OPTIONS|BGE_PCIMISCCTL_CLEAR_INTA| \ BGE_PCIMISCCTL_MASK_PCI_INTR|BGE_PCIMISCCTL_INDIRECT_ACCESS) -#define BGE_CHIPID_TIGON_I 0x40000000 -#define BGE_CHIPID_TIGON_II 0x60000000 -#define BGE_CHIPID_BCM5700_A0 0x70000000 -#define BGE_CHIPID_BCM5700_A1 0x70010000 -#define BGE_CHIPID_BCM5700_B0 0x71000000 -#define BGE_CHIPID_BCM5700_B1 0x71010000 -#define BGE_CHIPID_BCM5700_B2 0x71020000 -#define BGE_CHIPID_BCM5700_B3 0x71030000 -#define BGE_CHIPID_BCM5700_ALTIMA 0x71040000 -#define BGE_CHIPID_BCM5700_C0 0x72000000 -#define BGE_CHIPID_BCM5701_A0 0x00000000 /* grrrr */ -#define BGE_CHIPID_BCM5701_B0 0x01000000 -#define BGE_CHIPID_BCM5701_B2 0x01020000 -#define BGE_CHIPID_BCM5701_B5 0x01050000 -#define BGE_CHIPID_BCM5703_A0 0x10000000 -#define BGE_CHIPID_BCM5703_A1 0x10010000 -#define BGE_CHIPID_BCM5703_A2 0x10020000 -#define BGE_CHIPID_BCM5703_A3 0x10030000 -#define BGE_CHIPID_BCM5703_B0 0x11000000 -#define BGE_CHIPID_BCM5704_A0 0x20000000 -#define BGE_CHIPID_BCM5704_A1 0x20010000 -#define BGE_CHIPID_BCM5704_A2 0x20020000 -#define BGE_CHIPID_BCM5704_A3 0x20030000 -#define BGE_CHIPID_BCM5704_B0 0x21000000 -#define BGE_CHIPID_BCM5705_A0 0x30000000 -#define BGE_CHIPID_BCM5705_A1 0x30010000 -#define BGE_CHIPID_BCM5705_A2 0x30020000 -#define BGE_CHIPID_BCM5705_A3 0x30030000 -#define BGE_CHIPID_BCM5750_A0 0x40000000 -#define BGE_CHIPID_BCM5750_A1 0x40010000 -#define BGE_CHIPID_BCM5750_A3 0x40030000 -#define BGE_CHIPID_BCM5750_B0 0x41000000 -#define BGE_CHIPID_BCM5750_B1 0x41010000 -#define BGE_CHIPID_BCM5750_C0 0x42000000 -#define BGE_CHIPID_BCM5750_C1 0x42010000 -#define BGE_CHIPID_BCM5750_C2 0x42020000 -#define BGE_CHIPID_BCM5714_A0 0x50000000 -#define BGE_CHIPID_BCM5752_A0 0x60000000 -#define BGE_CHIPID_BCM5752_A1 0x60010000 -#define BGE_CHIPID_BCM5752_A2 0x60020000 -#define BGE_CHIPID_BCM5714_B0 0x80000000 -#define BGE_CHIPID_BCM5714_B3 0x80030000 -#define BGE_CHIPID_BCM5715_A0 0x90000000 -#define BGE_CHIPID_BCM5715_A1 0x90010000 -#define BGE_CHIPID_BCM5715_A3 0x90030000 -#define BGE_CHIPID_BCM5755_A0 0xa0000000 -#define BGE_CHIPID_BCM5755_A1 0xa0010000 -#define BGE_CHIPID_BCM5755_A2 0xa0020000 -#define BGE_CHIPID_BCM5722_A0 0xa2000000 -#define BGE_CHIPID_BCM5754_A0 0xb0000000 -#define BGE_CHIPID_BCM5754_A1 0xb0010000 -#define BGE_CHIPID_BCM5754_A2 0xb0020000 -#define BGE_CHIPID_BCM5787_A0 0xb0000000 -#define BGE_CHIPID_BCM5787_A1 0xb0010000 -#define BGE_CHIPID_BCM5787_A2 0xb0020000 -#define BGE_CHIPID_BCM5906_A1 0xc0010000 -#define BGE_CHIPID_BCM5906_A2 0xc0020000 +#define BGE_CHIPID_TIGON_I 0x4000 +#define BGE_CHIPID_TIGON_II 0x6000 +#define BGE_CHIPID_BCM5700_A0 0x7000 +#define BGE_CHIPID_BCM5700_A1 0x7001 +#define BGE_CHIPID_BCM5700_B0 0x7100 +#define BGE_CHIPID_BCM5700_B1 0x7101 +#define BGE_CHIPID_BCM5700_B2 0x7102 +#define BGE_CHIPID_BCM5700_B3 0x7103 +#define BGE_CHIPID_BCM5700_ALTIMA 0x7104 +#define BGE_CHIPID_BCM5700_C0 0x7200 +#define BGE_CHIPID_BCM5701_A0 0x0000 /* grrrr */ +#define BGE_CHIPID_BCM5701_B0 0x0100 +#define BGE_CHIPID_BCM5701_B2 0x0102 +#define BGE_CHIPID_BCM5701_B5 0x0105 +#define BGE_CHIPID_BCM5703_A0 0x1000 +#define BGE_CHIPID_BCM5703_A1 0x1001 +#define BGE_CHIPID_BCM5703_A2 0x1002 +#define BGE_CHIPID_BCM5703_A3 0x1003 +#define BGE_CHIPID_BCM5703_B0 0x1100 +#define BGE_CHIPID_BCM5704_A0 0x2000 +#define BGE_CHIPID_BCM5704_A1 0x2001 +#define BGE_CHIPID_BCM5704_A2 0x2002 +#define BGE_CHIPID_BCM5704_A3 0x2003 +#define BGE_CHIPID_BCM5704_B0 0x2100 +#define BGE_CHIPID_BCM5705_A0 0x3000 +#define BGE_CHIPID_BCM5705_A1 0x3001 +#define BGE_CHIPID_BCM5705_A2 0x3002 +#define BGE_CHIPID_BCM5705_A3 0x3003 +#define BGE_CHIPID_BCM5750_A0 0x4000 +#define BGE_CHIPID_BCM5750_A1 0x4001 +#define BGE_CHIPID_BCM5750_A3 0x4000 +#define BGE_CHIPID_BCM5750_B0 0x4100 +#define BGE_CHIPID_BCM5750_B1 0x4101 +#define BGE_CHIPID_BCM5750_C0 0x4200 +#define BGE_CHIPID_BCM5750_C1 0x4201 +#define BGE_CHIPID_BCM5750_C2 0x4202 +#define BGE_CHIPID_BCM5714_A0 0x5000 +#define BGE_CHIPID_BCM5752_A0 0x6000 +#define BGE_CHIPID_BCM5752_A1 0x6001 +#define BGE_CHIPID_BCM5752_A2 0x6002 +#define BGE_CHIPID_BCM5714_B0 0x8000 +#define BGE_CHIPID_BCM5714_B3 0x8003 +#define BGE_CHIPID_BCM5715_A0 0x9000 +#define BGE_CHIPID_BCM5715_A1 0x9001 +#define BGE_CHIPID_BCM5715_A3 0x9003 +#define BGE_CHIPID_BCM5755_A0 0xa000 +#define BGE_CHIPID_BCM5755_A1 0xa001 +#define BGE_CHIPID_BCM5755_A2 0xa002 +#define BGE_CHIPID_BCM5722_A0 0xa200 +#define BGE_CHIPID_BCM5754_A0 0xb000 +#define BGE_CHIPID_BCM5754_A1 0xb001 +#define BGE_CHIPID_BCM5754_A2 0xb002 +#define BGE_CHIPID_BCM5761_A0 0x5761000 +#define BGE_CHIPID_BCM5761_A1 0x5761100 +#define BGE_CHIPID_BCM5784_A0 0x5784000 +#define BGE_CHIPID_BCM5784_A1 0x5784100 +#define BGE_CHIPID_BCM5787_A0 0xb000 +#define BGE_CHIPID_BCM5787_A1 0xb001 +#define BGE_CHIPID_BCM5787_A2 0xb002 +#define BGE_CHIPID_BCM5906_A1 0xc001 +#define BGE_CHIPID_BCM5906_A2 0xc002 +#define BGE_CHIPID_BCM57780_A0 0x57780000 +#define BGE_CHIPID_BCM57780_A1 0x57780001 /* shorthand one */ -#define BGE_ASICREV(x) ((x) >> 28) +#define BGE_ASICREV(x) ((x) >> 12) #define BGE_ASICREV_BCM5701 0x00 #define BGE_ASICREV_BCM5703 0x01 #define BGE_ASICREV_BCM5704 0x02 @@ -319,9 +327,16 @@ #define BGE_ASICREV_BCM5754 0x0b #define BGE_ASICREV_BCM5787 0x0b #define BGE_ASICREV_BCM5906 0x0c +/* Should consult BGE_PCI_PRODID_ASICREV for ChipID */ +#define BGE_ASICREV_USE_PRODID_REG 0x0f +/* BGE_PCI_PRODID_ASICREV ASIC rev. identifiers. */ +#define BGE_ASICREV_BCM5761 0x5761 +#define BGE_ASICREV_BCM5784 0x5784 +#define BGE_ASICREV_BCM5785 0x5785 +#define BGE_ASICREV_BCM57780 0x57780 /* chip revisions */ -#define BGE_CHIPREV(x) ((x) >> 24) +#define BGE_CHIPREV(x) ((x) >> 8) #define BGE_CHIPREV_5700_AX 0x70 #define BGE_CHIPREV_5700_BX 0x71 #define BGE_CHIPREV_5700_CX 0x72 @@ -331,6 +346,9 @@ #define BGE_CHIPREV_5704_BX 0x21 #define BGE_CHIPREV_5750_AX 0x40 #define BGE_CHIPREV_5750_BX 0x41 +/* BGE_PCI_PRODID_ASICREV chip rev. identifiers. */ +#define BGE_CHIPREV_5761_AX 0x57611 +#define BGE_CHIPREV_5784_AX 0x57841 /* PCI DMA Read/Write Control register */ #define BGE_PCIDMARWCTL_MINDMA 0x000000FF @@ -861,6 +879,7 @@ #define BGE_SDCMODE_RESET 0x00000001 #define BGE_SDCMODE_ENABLE 0x00000002 #define BGE_SDCMODE_ATTN 0x00000004 +#define BGE_SDCMODE_CDELAY 0x00000010 /* Send Data completion status register */ #define BGE_SDCSTAT_ATTN 0x00000004 @@ -1378,6 +1397,9 @@ #define BGE_RDMAMODE_PCI_FIFOOREAD_ATTN 0x00000100 #define BGE_RDMAMODE_LOCWRITE_TOOBIG 0x00000200 #define BGE_RDMAMODE_ALL_ATTNS 0x000003FC +#define BGE_RDMAMODE_BD_SBD_CRPT_ATTN 0x00000800 +#define BGE_RDMAMODE_MBUF_RBD_CRPT_ATTN 0x00001000 +#define BGE_RDMAMODE_MBUF_SBD_CRPT_ATTN 0x00002000 #define BGE_RDMAMODE_FIFO_SIZE_128 0x00020000 #define BGE_RDMAMODE_FIFO_LONG_BURST 0x00030000 @@ -2101,6 +2123,7 @@ struct bge_status_block { #define BCOM_DEVICEID_BCM5720 0x1658 #define BCOM_DEVICEID_BCM5721 0x1659 #define BCOM_DEVICEID_BCM5722 0x165A +#define BCOM_DEVICEID_BCM5723 0x165B #define BCOM_DEVICEID_BCM5750 0x1676 #define BCOM_DEVICEID_BCM5750M 0x167C #define BCOM_DEVICEID_BCM5751 0x1677 @@ -2115,13 +2138,22 @@ struct bge_status_block { #define BCOM_DEVICEID_BCM5754M 0x1672 #define BCOM_DEVICEID_BCM5755 0x167B #define BCOM_DEVICEID_BCM5755M 0x1673 +#define BCOM_DEVICEID_BCM5761 0x1681 +#define BCOM_DEVICEID_BCM5761E 0x1680 +#define BCOM_DEVICEID_BCM5761S 0x1688 +#define BCOM_DEVICEID_BCM5761SE 0x1689 +#define BCOM_DEVICEID_BCM5764 0x1684 #define BCOM_DEVICEID_BCM5780 0x166A #define BCOM_DEVICEID_BCM5780S 0x166B #define BCOM_DEVICEID_BCM5781 0x16DD #define BCOM_DEVICEID_BCM5782 0x1696 +#define BCOM_DEVICEID_BCM5784 0x1698 +#define BCOM_DEVICEID_BCM5785F 0x16a0 +#define BCOM_DEVICEID_BCM5785G 0x1699 #define BCOM_DEVICEID_BCM5786 0x169A #define BCOM_DEVICEID_BCM5787 0x169B #define BCOM_DEVICEID_BCM5787M 0x1693 +#define BCOM_DEVICEID_BCM5787F 0x167f #define BCOM_DEVICEID_BCM5788 0x169C #define BCOM_DEVICEID_BCM5789 0x169D #define BCOM_DEVICEID_BCM5901 0x170D @@ -2129,6 +2161,10 @@ struct bge_status_block { #define BCOM_DEVICEID_BCM5903M 0x16FF #define BCOM_DEVICEID_BCM5906 0x1712 #define BCOM_DEVICEID_BCM5906M 0x1713 +#define BCOM_DEVICEID_BCM57760 0x1690 +#define BCOM_DEVICEID_BCM57780 0x1692 +#define BCOM_DEVICEID_BCM57788 0x1691 +#define BCOM_DEVICEID_BCM57790 0x1694 /* * Alteon AceNIC PCI vendor/device ID. @@ -2179,6 +2215,14 @@ struct bge_status_block { #define SUN_VENDORID 0x108e /* + * Fujitsu vendor/device IDs + */ +#define FJTSU_VENDORID 0x10cf +#define FJTSU_DEVICEID_PW008GE5 0x11a1 +#define FJTSU_DEVICEID_PW008GE4 0x11a2 +#define FJTSU_DEVICEID_PP250450 0x11cc /* PRIMEPOWER250/450 LAN */ + +/* * Offset of MAC address inside EEPROM. */ #define BGE_EE_MAC_OFFSET 0x7C @@ -2558,6 +2602,7 @@ struct bge_softc { #define BGE_FLAG_5705_PLUS 0x00002000 #define BGE_FLAG_5714_FAMILY 0x00004000 #define BGE_FLAG_575X_PLUS 0x00008000 +#define BGE_FLAG_5755_PLUS 0x00010000 #define BGE_FLAG_RX_ALIGNBUG 0x00100000 #define BGE_FLAG_NO_3LED 0x00200000 #define BGE_FLAG_ADC_BUG 0x00400000 @@ -2568,8 +2613,8 @@ struct bge_softc { #define BGE_FLAG_CRC_BUG 0x08000000 #define BGE_FLAG_5788 0x20000000 uint32_t bge_chipid; - uint8_t bge_asicrev; - uint8_t bge_chiprev; + uint32_t bge_asicrev; + uint32_t bge_chiprev; uint8_t bge_asf_mode; uint8_t bge_asf_count; struct bge_ring_data bge_ldata; /* rings */ _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From rwatson at FreeBSD.org Wed Oct 7 13:40:20 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Oct 7 13:40:27 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACC8CC8.8050403@mail.ru> References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> <4ACC5563.602@mail.ru> <4ACC56A6.1030808@mail.ru> <4ACC5DEC.1010006@mail.ru> <4ACC65A0.7030900@mail.ru> <4ACC8CC8.8050403@mail.ru> Message-ID: On Wed, 7 Oct 2009, rihad wrote: >> Suggestions like increasing timer resolution are intended to spread out the >> injection of packets by dummynet to attempt to reduce the peaks of >> burstiness that occur when multiple queues inject packets in a burst that >> exceeds the queue depth supported by combined hardware descriptor rings and >> software transmit queue. > > Raising HZ from 1000 to 2000 has helped. There are now 200-300 global > drops/s, as opposed to 300-1000 with HZ=1000. Or maybe net.isr.direct from 1 > to 0 help. Or maybe hash_size from 64 to 256. Or maybe... Or maybe other random factors such as traffic load corresponding to major sports events, etc. :-) It's also possible that combining multiple changes cancels out the effect of one or another change. Given the rather large number of possible combinations of things to try, I'd suggest being fairly strategic in how you try them. Starting with just an original config + significant HZ increase is probably the best starting point. Changing hash_size is really about reducing CPU use, so if in the whole you're not getting close to the capacity of a core for any given thread involved in the work, it may not make much difference (tuning these data structures is a bit of a black art). >> The two solutions, then are (a) to increase the timer resolution >> significantly so that packets are injected in smaller bursts > > But isn't that bad that it can actually become worse? From /sys/conf/NOTES: > > # The granularity of operation is controlled by the kernel option HZ whose > # default value (1000 on most architectures) means a granularity of 1ms > # (1s/HZ). Historically, the default was 100, but finer granularity is > # required for DUMMYNET and other systems on modern hardware. There are > # reasonable arguments that HZ should, in fact, be 100 still; consider, > # that reducing the granularity too much might cause excessive overhead in > # clock interrupt processing, potentially causing ticks to be missed and thus > # actually reducing the accuracy of operation. Right: we fire the timer on every CPU at 1/HZ seconds, which means quite a lot of work being done. On systems where timers are proportionally more expensive -- especially when using hardware virtualization, for example, we do recommend tuning the timers down. And our boot loader will actually do it for you: we auto-detect vmware, parallels, kqemu, virtualbox, etc, and adjust the timer rate from from 1000 to 100 during the boot. That said, in your configuration I see little argument for a lower timer rate: you need to burst packets at frequent intervals or risk overfilling queues, and the overheads of additional timer tickets on your system shouldn't be too bad as you have both very fast hardware and a lot of idle time. I would suggest making just the HZ -> 4000 change for now and see how it goes. >> and (b) increase the queue capacities. The hardware queue limits likely >> can't be raised w/o new hardware, but the ifnet transmit queue sizes can be >> increased. > > Can someone please say how to increase the "ifnet transmit queue sizes"? Unfortunately, I fear that this is driver-specific, and in the case of bce requires a recompile. In the driver init code in if_bce, the following code appears: ifp->if_snd.ifq_drv_maxlen = USABLE_TX_BD; IFQ_SET_MAXLEN(&ifp->if_snd, ifp->if_snd.ifq_drv_maxlen); IFQ_SET_READY(&ifp->if_snd); Which evaluates to a architecture-specific value due to varying pagesize. You might just try forcing it to 1024. >> Timer resolution going up is almost certainly not a bad idea in your >> configuration, although does require a reboot as you have observed. > > OK, I'll try HZ=4000, but there are some required servers like > flowtools/radius/mysql/perl app that are also running. That should be fine. >> On a side note: one other possible interpretation of that statistic is that >> you're seeing fragmentation problems. Usually in forwarding scenarios this >> is unlikely. However, it wouldn't hurt to make sure you have LRO turned >> off on the network interfaces you're using, assuming it's supported by the >> driver. >> > I don't think fragments are the problem. The numbers are too small ;-) > $ netstat -s|fgrep fragment > 5318 fragments received > 147 fragments dropped (dup or out of space) > 5157 fragments dropped after timeout > 4088 output datagrams fragmented > 8180 fragments created > 0 datagrams that can't be fragmented > > There's no such option as LRO shown, so I guess it's off: > options=1bb That probably rules that out as a source of problems then. Robert From rihad at mail.ru Wed Oct 7 14:43:59 2009 From: rihad at mail.ru (rihad) Date: Wed Oct 7 14:44:06 2009 Subject: dummynet dropping too many packets In-Reply-To: References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> <4ACC5563.602@mail.ru> <4ACC56A6.1030808@mail.ru> <4ACC5DEC.1010006@mail.ru> <4ACC65A0.7030900@mail.ru> <4ACC8CC8.8050403@mail.ru> Message-ID: <4ACCA92A.9070803@mail.ru> Robert Watson wrote: > I would suggest making just the HZ -> 4000 change for now and see how it > goes. > OK, I will try testing HZ=4000 tomorrow morning, although I'm pretty sure there still will be some drops. >> Can someone please say how to increase the "ifnet transmit queue sizes"? > > Unfortunately, I fear that this is driver-specific, and in the case of > bce requires a recompile. In the driver init code in if_bce, the > following code appears: > > ifp->if_snd.ifq_drv_maxlen = USABLE_TX_BD; > IFQ_SET_MAXLEN(&ifp->if_snd, ifp->if_snd.ifq_drv_maxlen); > IFQ_SET_READY(&ifp->if_snd); > > Which evaluates to a architecture-specific value due to varying > pagesize. You might just try forcing it to 1024. > I think I'll try this too, if HZ=4000 doesn't help, thanks a lot. In the long run we'll switch to some high-quality 10 GiGE cards. From if at xip.at Wed Oct 7 14:49:25 2009 From: if at xip.at (Ingo Flaschberger) Date: Wed Oct 7 14:49:32 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACCA92A.9070803@mail.ru> References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> <4ACC5563.602@mail.ru> <4ACC56A6.1030808@mail.ru> <4ACC5DEC.1010006@mail.ru> <4ACC65A0.7030900@mail.ru> <4ACC8CC8.8050403@mail.ru> <4ACCA92A.9070803@mail.ru> Message-ID: Hi, can you send me the dmesg ouput from your networkcards when they are detected at booting? can you also send me a lspci and lspci -v ? Kind regards, ingo flaschberger From rihad at mail.ru Wed Oct 7 14:58:21 2009 From: rihad at mail.ru (rihad) Date: Wed Oct 7 14:58:28 2009 Subject: dummynet dropping too many packets In-Reply-To: References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> <4ACC5563.602@mail.ru> <4ACC56A6.1030808@mail.ru> <4ACC5DEC.1010006@mail.ru> <4ACC65A0.7030900@mail.ru> <4ACC8CC8.8050403@mail.ru> Message-ID: <4ACCAC89.1040805@mail.ru> Robert Watson wrote: > In the driver init code in if_bce, the following code appears: > > ifp->if_snd.ifq_drv_maxlen = USABLE_TX_BD; > IFQ_SET_MAXLEN(&ifp->if_snd, ifp->if_snd.ifq_drv_maxlen); > IFQ_SET_READY(&ifp->if_snd); > > Which evaluates to a architecture-specific value due to varying > pagesize. You might just try forcing it to 1024. > In dev/bce/if_bcereg.h: #define TX_PAGES 2 #define TOTAL_TX_BD_PER_PAGE (BCM_PAGE_SIZE / sizeof(struct tx_bd)) #define USABLE_TX_BD_PER_PAGE (TOTAL_TX_BD_PER_PAGE - 1) #define TOTAL_TX_BD (TOTAL_TX_BD_PER_PAGE * TX_PAGES) #define USABLE_TX_BD (USABLE_TX_BD_PER_PAGE * TX_PAGES) #define MAX_TX_BD (TOTAL_TX_BD - 1) meaning that ifq_drv_maxlen is expected to end up smaller than MAX_TX_BD. What if MAX_TX_BD is itself way smaller than 1024? From rihad at mail.ru Wed Oct 7 15:02:24 2009 From: rihad at mail.ru (rihad) Date: Wed Oct 7 15:02:30 2009 Subject: dummynet dropping too many packets In-Reply-To: References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> <4ACC5563.602@mail.ru> <4ACC56A6.1030808@mail.ru> <4ACC5DEC.1010006@mail.ru> <4ACC65A0.7030900@mail.ru> <4ACC8CC8.8050403@mail.ru> <4ACCA92A.9070803@mail.ru> Message-ID: <4ACCAD7D.9080207@mail.ru> Ingo Flaschberger wrote: > Hi, > > can you send me the dmesg ouput from your networkcards when they are > detected at booting? > Hello, bce0: mem 0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci7 bce0: Ethernet address: 00:1d:09:xx:xx:xx bce0: [ITHREAD] bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W (0x03050C05); Flags( MFW MSI ) bce1: mem 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci3 bce1: Ethernet address: 00:1d:09:xx:xx:xx bce1: [ITHREAD] bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W (0x03050C05); Flags( MFW MSI ) > can you also send me a lspci and lspci -v ? > Sorry, this is FreeBSD, not Linux ;-) # pciconf -l ... bce0@pci0:7:0:0: class=0x020000 card=0x01b21028 chip=0x164c14e4 rev=0x12 hdr=0x00 bce1@pci0:3:0:0: class=0x020000 card=0x01b21028 chip=0x164c14e4 rev=0x12 hdr=0x00 From if at xip.at Wed Oct 7 15:28:18 2009 From: if at xip.at (Ingo Flaschberger) Date: Wed Oct 7 15:28:26 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACCAD7D.9080207@mail.ru> References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> <4ACC5563.602@mail.ru> <4ACC56A6.1030808@mail.ru> <4ACC5DEC.1010006@mail.ru> <4ACC65A0.7030900@mail.ru> <4ACC8CC8.8050403@mail.ru> <4ACCA92A.9070803@mail.ru> <4ACCAD7D.9080207@mail.ru> Message-ID: Dear Rihad, >> can you also send me a lspci and lspci -v ? >> > Sorry, this is FreeBSD, not Linux ;-) you find a lspci in ports. Kind regards, Ingo Flaschberger From if at xip.at Wed Oct 7 15:41:52 2009 From: if at xip.at (Ingo Flaschberger) Date: Wed Oct 7 15:41:58 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACCAD7D.9080207@mail.ru> References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> <4ACC5563.602@mail.ru> <4ACC56A6.1030808@mail.ru> <4ACC5DEC.1010006@mail.ru> <4ACC65A0.7030900@mail.ru> <4ACC8CC8.8050403@mail.ru> <4ACCA92A.9070803@mail.ru> <4ACCAD7D.9080207@mail.ru> Message-ID: Dear Rihad, bge network card seems to have small tx/rx rings? If I understood the src/sys/dev/bge/if_bgereg.h correct, the ring size is 512 descriptors, while intel based cards (em) have up to 4096 descriptors. Kind regards, Ingo Flaschberger From rihad at mail.ru Wed Oct 7 15:50:59 2009 From: rihad at mail.ru (rihad) Date: Wed Oct 7 15:51:09 2009 Subject: dummynet dropping too many packets In-Reply-To: References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> <4ACC5563.602@mail.ru> <4ACC56A6.1030808@mail.ru> <4ACC5DEC.1010006@mail.ru> <4ACC65A0.7030900@mail.ru> <4ACC8CC8.8050403@mail.ru> <4ACCA92A.9070803@mail.ru> <4ACCAD7D.9080207@mail.ru> Message-ID: <4ACCB8DD.5040205@mail.ru> Ingo Flaschberger wrote: > Dear Rihad, > > bge network card seems to have small tx/rx rings? > If I understood the src/sys/dev/bge/if_bgereg.h correct, the > ring size is 512 descriptors, while intel based cards > (em) have up to 4096 descriptors. > We have bce, not bge. I'm gonna try HZ=4000 tomorrow and see if that helps. From julian at elischer.org Wed Oct 7 16:34:20 2009 From: julian at elischer.org (Julian Elischer) Date: Wed Oct 7 16:34:27 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACC7308.6070301@mail.ru> References: <4AC8A76B.3050502@mail.ru> <20091007085902.GA88982@lath.rinet.ru> <4ACC5E23.8090405@mail.ru> <20091007100503.GB88982@lath.rinet.ru> <4ACC6A7B.5050808@mail.ru> <20091007104525.GC88982@lath.rinet.ru> <4ACC7308.6070301@mail.ru> Message-ID: <4ACCC30E.7080504@elischer.org> rihad wrote: > Oleg Bulyzhin wrote: > You probably have some special sources of documentation ;-) According to > man ipfw, both "netgraph/ngtee" and "pipe" decide the fate of the packet > unless one_pass=0. Or do you mean sprinkling smart skiptos here and > there? ;-) > ngtee should not have any affect on the packet.. it takes a copy.. From rihad at mail.ru Wed Oct 7 16:42:33 2009 From: rihad at mail.ru (rihad) Date: Wed Oct 7 16:42:47 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACCC30E.7080504@elischer.org> References: <4AC8A76B.3050502@mail.ru> <20091007085902.GA88982@lath.rinet.ru> <4ACC5E23.8090405@mail.ru> <20091007100503.GB88982@lath.rinet.ru> <4ACC6A7B.5050808@mail.ru> <20091007104525.GC88982@lath.rinet.ru> <4ACC7308.6070301@mail.ru> <4ACCC30E.7080504@elischer.org> Message-ID: <4ACCC4F3.3030302@mail.ru> Julian Elischer wrote: > rihad wrote: >> Oleg Bulyzhin wrote: > >> You probably have some special sources of documentation ;-) According >> to man ipfw, both "netgraph/ngtee" and "pipe" decide the fate of the >> packet unless one_pass=0. Or do you mean sprinkling smart skiptos here >> and there? ;-) >> > > ngtee should not have any affect on the packet.. it takes a copy.. > That's a logical conclusion, although I prefer trusting the man at hand (pun intended) if I haven't tested it myself to see how it works: ngtee cookie A copy of packet is diverted into netgraph, original packet is either accepted or continues with the next rule, depending on net.inet.ip.fw.one_pass sysctl variable. See ng_ipfw(4) for more information on netgraph and ngtee actions. Although... I've a question to Mr. Oleg: > 2) use 'tee' rule with ng_ksocket & ng_netflow tee port Send a copy of packets matching this rule to the divert(4) socket bound to port port. The search continues with the next rule. how is it different from one_pass=0? Both tee and ngtee w/ one_pass=0 continue with the next rule. From julian at elischer.org Wed Oct 7 16:49:54 2009 From: julian at elischer.org (Julian Elischer) Date: Wed Oct 7 16:50:01 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACCA92A.9070803@mail.ru> References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> <4ACC5563.602@mail.ru> <4ACC56A6.1030808@mail.ru> <4ACC5DEC.1010006@mail.ru> <4ACC65A0.7030900@mail.ru> <4ACC8CC8.8050403@mail.ru> <4ACCA92A.9070803@mail.ru> Message-ID: <4ACCC6B3.3020903@elischer.org> rihad wrote: > Robert Watson wrote: > >> I would suggest making just the HZ -> 4000 change for now and see how >> it goes. >> > OK, I will try testing HZ=4000 tomorrow morning, although I'm pretty > sure there still will be some drops. > >>> Can someone please say how to increase the "ifnet transmit queue sizes"? >> >> Unfortunately, I fear that this is driver-specific, and in the case of >> bce requires a recompile. In the driver init code in if_bce, the >> following code appears: >> >> ifp->if_snd.ifq_drv_maxlen = USABLE_TX_BD; >> IFQ_SET_MAXLEN(&ifp->if_snd, ifp->if_snd.ifq_drv_maxlen); >> IFQ_SET_READY(&ifp->if_snd); >> >> Which evaluates to a architecture-specific value due to varying >> pagesize. You might just try forcing it to 1024. >> > I think I'll try this too, if HZ=4000 doesn't help, thanks a lot. > In the long run we'll switch to some high-quality 10 GiGE cards. for output.. It may still be possible for the output queues to be overrun as teh bursts from dummynet can be much faster than even 10G hardware can dispose of the data. From gleb.kurtsou at gmail.com Wed Oct 7 17:50:04 2009 From: gleb.kurtsou at gmail.com (Gleb Kurtsou) Date: Wed Oct 7 17:50:10 2009 Subject: bin/139346: [patch] arp(8) add option to remove static entries listed in file Message-ID: <200910071750.n97Ho3Ja007466@freefall.freebsd.org> The following reply was made to PR bin/139346; it has been noted by GNATS. From: Gleb Kurtsou To: gavin@FreeBSD.org, bug-followup@FreeBSD.org Cc: Subject: Re: bin/139346: [patch] arp(8) add option to remove static entries listed in file Date: Wed, 7 Oct 2009 20:40:53 +0300 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Updated patch attached: includes man page update. --zhXaljGHf11kAtnf Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="arp-df-2.path.txt" diff --git a/usr.sbin/arp/arp.8 b/usr.sbin/arp/arp.8 index d7306d3..683ec42 100644 --- a/usr.sbin/arp/arp.8 +++ b/usr.sbin/arp/arp.8 @@ -51,6 +51,8 @@ .Op Fl i Ar interface .Fl a .Nm +.Fl d Fl f Ar filename +.Nm .Fl s Ar hostname ether_addr .Op Cm temp .Op Cm blackhole No \&| Cm reject @@ -99,7 +101,9 @@ Alternatively, the .Fl d flag may be combined with the .Fl a -flag to delete all entries. +flag to delete all entries or with +.Fl f +flag to delete all entries listed in file. .It Fl i Ar interface Limit the operation scope to the .Tn ARP @@ -174,6 +178,11 @@ Cause the file to be read and multiple entries to be set in the .Tn ARP tables. +Combining with +.Fl d +flag may be used to delete entries from the +.Tn ARP +tables. Entries in the file should be of the form .Pp diff --git a/usr.sbin/arp/arp.c b/usr.sbin/arp/arp.c index 8a3410f..11d1df6 100644 --- a/usr.sbin/arp/arp.c +++ b/usr.sbin/arp/arp.c @@ -101,7 +101,7 @@ static int valid_type(int type); static int nflag; /* no reverse dns lookups */ static char *rifname; -static int expire_time, flags, doing_proxy, proxy_only; +static int expire_time, flags, func, doing_proxy, proxy_only; /* which function we're supposed to do */ #define F_GET 1 @@ -109,23 +109,28 @@ static int expire_time, flags, doing_proxy, proxy_only; #define F_FILESET 3 #define F_REPLACE 4 #define F_DELETE 5 +#define F_FILEDELETE 6 #define SETFUNC(f) { if (func) usage(); func = (f); } int main(int argc, char *argv[]) { - int ch, func = 0; + int ch; int rtn = 0; int aflag = 0; /* do it for all entries */ + func = 0; while ((ch = getopt(argc, argv, "andfsSi:")) != -1) switch(ch) { case 'a': aflag = 1; break; case 'd': - SETFUNC(F_DELETE); + if (func == F_FILESET) + func = F_FILEDELETE; + else + SETFUNC(F_DELETE); break; case 'n': nflag = 1; @@ -137,7 +142,10 @@ main(int argc, char *argv[]) SETFUNC(F_SET); break; case 'f' : - SETFUNC(F_FILESET); + if (func == F_DELETE) + func = F_FILEDELETE; + else + SETFUNC(F_FILESET); break; case 'i': rifname = optarg; @@ -197,6 +205,7 @@ main(int argc, char *argv[]) } break; case F_FILESET: + case F_FILEDELETE: if (argc != 1) usage(); rtn = file(argv[0]); @@ -213,7 +222,7 @@ static int file(char *name) { FILE *fp; - int i, retval; + int i, j, retval; char line[100], arg[5][50], *args[5], *p; if ((fp = fopen(name, "r")) == NULL) @@ -237,8 +246,23 @@ file(char *name) retval = 1; continue; } - if (set(i, args)) - retval = 1; + switch (func) { + case F_FILESET: + if (set(i, args)) + retval = 1; + break; + case F_FILEDELETE: + for (j = 2; j < i; j++) + if (strncmp(args[j], "pub", 3) == 0) { + j = 0; + break; + } + if (delete(args[0], j == 0 ? SIN_PROXY : 0)) + retval = 1; + break; + default: + usage(); + } } fclose(fp); return (retval); @@ -650,11 +674,12 @@ nuke_entry(struct sockaddr_dl *sdl __unused, static void usage(void) { - fprintf(stderr, "%s\n%s\n%s\n%s\n%s\n%s\n%s\n", + fprintf(stderr, "%s\n%s\n%s\n%s\n%s\n%s\n%s\n%s\n", "usage: arp [-n] [-i interface] hostname", " arp [-n] [-i interface] -a", " arp -d hostname [pub]", " arp -d [-i interface] -a", + " arp -d -f filename", " arp -s hostname ether_addr [temp] [reject | blackhole] [pub [only]]", " arp -S hostname ether_addr [temp] [reject | blackhole] [pub [only]]", " arp -f filename"); --zhXaljGHf11kAtnf-- From linimon at FreeBSD.org Wed Oct 7 18:01:56 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Oct 7 18:02:02 2009 Subject: kern/139387: [ipsec] Wrong lenth of PF_KEY messages in promiscuous mode Message-ID: <200910071801.n97I1u5B023875@freefall.freebsd.org> Old Synopsis: Wrong lenth of PF_KEY messages in promiscuous mode New Synopsis: [ipsec] Wrong lenth of PF_KEY messages in promiscuous mode Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Oct 7 18:00:49 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=139387 From j at joostm.nl Wed Oct 7 18:55:21 2009 From: j at joostm.nl (Joost Mulders) Date: Wed Oct 7 18:55:28 2009 Subject: recommended PCI for wlan AP Message-ID: <91A98EB1-FFB3-4462-BE8C-BFEB2A215BF0@joostm.nl> Hi all, I'm preparing the build of my "residential gateway", a home storage server and router. I could use recommendations for a PCI wlan adapter that works well in AP mode (a/b/g). Thanks much! Joost From j at joostm.nl Wed Oct 7 18:56:37 2009 From: j at joostm.nl (Joost Mulders) Date: Wed Oct 7 18:56:44 2009 Subject: PCI card for wlan AP Message-ID: <768BD7F8-7B04-4111-8A69-0D1118361E96@joostm.nl> Howdy, Can you recommend a WLAN PCI card for AP use in my FreeBSD "residential gateway". I'm looking for a 802.11 a/b/g card, no need for "n" yet. Recommendations and "works for me's" are highly appreciated. Thank you, Joost From spawk at acm.poly.edu Wed Oct 7 19:06:10 2009 From: spawk at acm.poly.edu (Boris Kochergin) Date: Wed Oct 7 19:06:17 2009 Subject: PCI card for wlan AP In-Reply-To: <768BD7F8-7B04-4111-8A69-0D1118361E96@joostm.nl> References: <768BD7F8-7B04-4111-8A69-0D1118361E96@joostm.nl> Message-ID: <4ACCE651.1060607@acm.poly.edu> Joost Mulders wrote: > Howdy, > > Can you recommend a WLAN PCI card for AP use in my FreeBSD > "residential gateway". I'm looking for a 802.11 a/b/g card, no need > for "n" yet. > > Recommendations and "works for me's" are highly appreciated. > > Thank you, Joost > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" I have a ton of these that I'm very happy with: http://www.newegg.com/Product/Product.aspx?Item=N82E16833127075 The heavily-used ones exhibit the problem described at: http://lists.freebsd.org/pipermail/freebsd-net/2009-September/022894.html ...but that's a driver, not a hardware, issue. The one in the router at my house doesn't exhibit the problem, the two differences there being that the machine is 7.0-RELEASE, and there are only a couple of clients connected to it, as opposed to the ~30 connected to my heavily-used ones. -Boris From rpaulo at freebsd.org Wed Oct 7 19:24:45 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Wed Oct 7 19:25:18 2009 Subject: recommended PCI for wlan AP In-Reply-To: <91A98EB1-FFB3-4462-BE8C-BFEB2A215BF0@joostm.nl> References: <91A98EB1-FFB3-4462-BE8C-BFEB2A215BF0@joostm.nl> Message-ID: <5F574815-77C8-43B3-9737-9CB5FD7CF288@freebsd.org> On 4 Oct 2009, at 20:58, Joost Mulders wrote: > Hi all, > > I'm preparing the build of my "residential gateway", a home storage > server and router. I could use recommendations for a PCI wlan > adapter that works well in AP mode (a/b/g). Wistron cards work well for me. -- Rui Paulo From rpaulo at freebsd.org Wed Oct 7 19:27:15 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Wed Oct 7 19:27:22 2009 Subject: PCI card for wlan AP In-Reply-To: <4ACCE651.1060607@acm.poly.edu> References: <768BD7F8-7B04-4111-8A69-0D1118361E96@joostm.nl> <4ACCE651.1060607@acm.poly.edu> Message-ID: <824A1142-42E3-4B2E-AE72-489AD5AB7D49@freebsd.org> On 7 Oct 2009, at 20:04, Boris Kochergin wrote: > > The heavily-used ones exhibit the problem described at: > > http://lists.freebsd.org/pipermail/freebsd-net/2009-September/022894.html > > ...but that's a driver, not a hardware, issue. The one in the router > at my house doesn't exhibit the problem, the two differences there > being that the machine is 7.0-RELEASE, and there are only a couple > of clients connected to it, as opposed to the ~30 connected to my > heavily-used ones. Are you sure you have sufficient RAM to hold 30 users? What you seem to be saying is that the ath driver is leaking mbufs and hence you get a panic, right? -- Rui Paulo From nlandys at gmail.com Wed Oct 7 19:52:50 2009 From: nlandys at gmail.com (Nerius Landys) Date: Wed Oct 7 19:53:11 2009 Subject: recommended PCI for wlan AP In-Reply-To: <5F574815-77C8-43B3-9737-9CB5FD7CF288@freebsd.org> References: <91A98EB1-FFB3-4462-BE8C-BFEB2A215BF0@joostm.nl> <5F574815-77C8-43B3-9737-9CB5FD7CF288@freebsd.org> Message-ID: <560f92640910071228n3fa8f408j665a9275ba937c53@mail.gmail.com> >> I'm preparing the build of my "residential gateway", a home storage server >> and router. I could use recommendations for a PCI wlan adapter that works >> well in AP mode (a/b/g). I have my FreeBSD box configured in AP mode. EnGenius Technologies EPI-3601S (600MW 802.11G PCI Card with Superg 108MBPS-Atheros) http://www.provantage.com/engenius-technologies-epi-3601s~7ENGN00W.htm This card works quite well for me. From spawk at acm.poly.edu Wed Oct 7 20:33:50 2009 From: spawk at acm.poly.edu (Boris Kochergin) Date: Wed Oct 7 20:33:57 2009 Subject: PCI card for wlan AP In-Reply-To: <824A1142-42E3-4B2E-AE72-489AD5AB7D49@freebsd.org> References: <768BD7F8-7B04-4111-8A69-0D1118361E96@joostm.nl> <4ACCE651.1060607@acm.poly.edu> <824A1142-42E3-4B2E-AE72-489AD5AB7D49@freebsd.org> Message-ID: <4ACCFADF.6090603@acm.poly.edu> Rui Paulo wrote: > On 7 Oct 2009, at 20:04, Boris Kochergin wrote: >> >> The heavily-used ones exhibit the problem described at: >> >> http://lists.freebsd.org/pipermail/freebsd-net/2009-September/022894.html >> >> >> ...but that's a driver, not a hardware, issue. The one in the router >> at my house doesn't exhibit the problem, the two differences there >> being that the machine is 7.0-RELEASE, and there are only a couple of >> clients connected to it, as opposed to the ~30 connected to my >> heavily-used ones. > > Are you sure you have sufficient RAM to hold 30 users? > > What you seem to be saying is that the ath driver is leaking mbufs and > hence you get a panic, right? > > -- > Rui Paulo > > > Pretty sure. The Soekris has 256 MB of RAM. I suspect that it's a leak because things are usually great, even with ~30 users, with the "80211node" portion from "vmstat -m" only taking a few hundred KiB of RAM. Every few days, it spikes to over 100 MiB, and the "ath0: ath_rx_proc: no mbuf!" kernel messages appear, often followed by a panic. I haven't had time to try another rate-control algorithm, as per the responses to my post, but I'll report back when I do get around to it. -Boris From rpaulo at FreeBSD.org Wed Oct 7 21:35:49 2009 From: rpaulo at FreeBSD.org (rpaulo@FreeBSD.org) Date: Wed Oct 7 21:35:55 2009 Subject: kern/137170: [ath] atheros AR9285 not recognised Message-ID: <200910072135.n97LZmtK005062@freefall.freebsd.org> Synopsis: [ath] atheros AR9285 not recognised Responsible-Changed-From-To: freebsd-net->rpaulo Responsible-Changed-By: rpaulo Responsible-Changed-When: Wed Oct 7 21:35:31 UTC 2009 Responsible-Changed-Why: I'm working on this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=137170 From lstewart at freebsd.org Wed Oct 7 22:02:35 2009 From: lstewart at freebsd.org (Lawrence Stewart) Date: Wed Oct 7 22:03:08 2009 Subject: Reproducible if_wpi panic "not enough data, data_len 2 space 1" on FreeBSD 9-CURRENT with WPA Message-ID: <4ACD0FEE.2040902@freebsd.org> Hi All, I have an Intel 3945ABG in my Toshiba R600 laptop which fairly reliably panics a while after I associate it with a WPA AP. It will happily associate and pass packets for some time (10's of minutes) and then panic. I have managed to trigger it both times I've tried to associate with this particular AP (some sort of NetGear 802.11n capable unit). Plenty of details here: http://people.freebsd.org/~lstewart/misc/wpi_debug/core.txt http://people.freebsd.org/~lstewart/misc/wpi_debug/kgdb_output.txt My /etc/wpa_supplicant.conf: ########## ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel network={ ssid="X" proto=WPA psk="Y" } ########## Suggestions most welcome. In particular, the comment above the KASSERT that is firing in frame 10 seems to indicate that some prodding at the logic in the michael_mic() function may be required. Cheers, Lawrence From onemda at gmail.com Wed Oct 7 23:17:18 2009 From: onemda at gmail.com (Paul B Mahol) Date: Wed Oct 7 23:17:33 2009 Subject: PCI card for wlan AP In-Reply-To: <4ACCFADF.6090603@acm.poly.edu> References: <768BD7F8-7B04-4111-8A69-0D1118361E96@joostm.nl> <4ACCE651.1060607@acm.poly.edu> <824A1142-42E3-4B2E-AE72-489AD5AB7D49@freebsd.org> <4ACCFADF.6090603@acm.poly.edu> Message-ID: <3a142e750910071617y2bc3b9e1r9af2d3ce54a818cd@mail.gmail.com> On 10/7/09, Boris Kochergin wrote: > Rui Paulo wrote: >> On 7 Oct 2009, at 20:04, Boris Kochergin wrote: >>> >>> The heavily-used ones exhibit the problem described at: >>> >>> http://lists.freebsd.org/pipermail/freebsd-net/2009-September/022894.html >>> >>> >>> >>> ...but that's a driver, not a hardware, issue. The one in the router >>> at my house doesn't exhibit the problem, the two differences there >>> being that the machine is 7.0-RELEASE, and there are only a couple of >>> clients connected to it, as opposed to the ~30 connected to my >>> heavily-used ones. >> >> Are you sure you have sufficient RAM to hold 30 users? >> >> What you seem to be saying is that the ath driver is leaking mbufs and >> hence you get a panic, right? >> >> -- >> Rui Paulo >> >> >> > Pretty sure. The Soekris has 256 MB of RAM. I suspect that it's a leak > because things are usually great, even with ~30 users, with the > "80211node" portion from "vmstat -m" only taking a few hundred KiB of > RAM. Every few days, it spikes to over 100 MiB, and the "ath0: Interesting, is it actually memory leak? (I try to hunt one down when using if_ndis(4) but without success) > ath_rx_proc: no mbuf!" kernel messages appear, often followed by a > panic. I haven't had time to try another rate-control algorithm, as per > the responses to my post, but I'll report back when I do get around to it. From mdounin at mdounin.ru Thu Oct 8 00:54:03 2009 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu Oct 8 00:54:11 2009 Subject: deadlock with pf uid rules + syncache Message-ID: <20091008003723.GD1229@mdounin.ru> Hello! We with ru@ investigated lockups our colleagues observing on RELENG_7 machines, and was able to track [at least some of] them down to the following deadlock: 1. syncache does syn+ack retransmit on timeout. it holds tcp_sc_head mutex, and output packet processed by pf which in turn waits for tcp lock to lookup uid. 2. em0 dispatches new ack packet to listen socket, tcp_input() holds tcp lock, syncache lookup requires tcp_sc_head. Here is data from ddb: db> bt 19 Tracing pid 19 tid 100011 td 0xc6ca0000 sched_switch(c6ca0000,0,1,c06388b0,a38b7a66,...) at sched_switch+0x320 mi_switch(1,0,c08455c6,2e3,c091d634,...) at mi_switch+0x143 turnstile_wait(c7881140,c6d76d80,1,bd5,c6d76d86,...) at turnstile_wait+0x234 _rw_rlock(c0966b8c,c73619f6,bd5,c736392c,ce3,...) at _rw_rlock+0x166 pf_socket_lookup(2,c6bc6a80,0,ce3,c6bc6a1c,...) at pf_socket_lookup+0xc8 pf_test_tcp(c6bc6b18,c6bc6b14,2,c7236400,c73c7800,...) at pf_test_tcp+0x86f pf_test(2,c704e800,c6bc6b74,0,0,...) at pf_test+0xde1 pf_check_out(0,c6bc6b74,c704e800,2,0,...) at pf_check_out+0x43 pfil_run_hooks(c0965e40,c6bc6c04,c704e800,2,0,...) at pfil_run_hooks+0x78 ip_output(c73c7800,0,c6bc6bd8,0,0,...) at ip_output+0x7c2 syncache_respond(c8929418,0,0,0,c0842ffa,...) at syncache_respond+0x255 syncache_timer(c6fd7ac0,0,c0842ffa,f1,1,...) at syncache_timer+0x127 softclock(0,0,c083f980,4cb,c6ce5070,...) at softclock+0x21f ithread_loop(c6c95330,c6bc6d38,c083f823,323,c6c97840,...) at ithread_loop+0x145 fork_exit(c05e7520,c6c95330,c6bc6d38) at fork_exit+0x94 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc6bc6d70, ebp = 0 --- db> bt 31 Tracing pid 31 tid 100031 td 0xc6d76d80 sched_switch(c6d76d80,0,1,c06388ee,a38981fa,...) at sched_switch+0x320 mi_switch(1,0,c08455c6,2e3,c091d7d8,...) at mi_switch+0x143 turnstile_wait(c7881be0,c6ca0000,0,c6fd7ac0,1f0,...) at turnstile_wait+0x234 _mtx_lock_sleep(c6fd7ac0,c6d76d80,0,c0850acb,1f0,...) at _mtx_lock_sleep+0x10e _mtx_lock_flags(c6fd7ac0,0,c0850acb,1f0,e6f87b14,...) at _mtx_lock_flags+0x67 syncache_lookup(e6f87aec,e6f87a8c,e6f8799c,c07db700,c091d8b8,...) at syncache_lookup+0x5e syncache_expand(e6f87aec,e6f87b14,c7593024,e6f87b2c,c753d600,...) at syncache_expand+0x1e tcp_input(c753d600,14,c704e800,1,0,...) at tcp_input+0x459 ip_input(c753d600,c057d932,800,c704e800,800,...) at ip_input+0x620 netisr_dispatch(2,c753d600,0,c7257537,3ac,...) at netisr_dispatch+0x55 ether_demux(c704e800,c753d600,3,0,3,...) at ether_demux+0x1aa ether_input(c704e800,c753d600,c6d76e18,c08baa84,c082d68e,...) at ether_input+0x343 ether_demux(c6da6000,c753d600,3,0,3,...) at ether_demux+0x107 ether_input(c6da6000,c753d600,c082d68e,11ba,c084572e,...) at ether_input+0x343 em_rxeof(e6f87ca4,c05f860d,c6da159c,8,c6dc832c,...) at em_rxeof+0x499 em_handle_rxtx(c6dc4000,1,c0845360,52,c6da159c,...) at em_handle_rxtx+0x2e taskqueue_run(c6da1580,c6da159c,c0836cc3,0,c083f823,...) at taskqueue_run+0x10b taskqueue_thread_loop(c6dc835c,e6f87d38,c083f823,323,c6dcbb00,...) at taskqueue_thread_loop+0x68 fork_exit(c0636ee0,c6dc835c,e6f87d38) at fork_exit+0x94 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe6f87d70, ebp = 0 --- db> show turnstile 0xc7881be0 Lock: 0xc6fd7ac0 - (sleep mutex) tcp_sc_head Lock Owner: 0xc6ca0000 (tid 100011, pid 19, "swi4: clock sio") Shared Waiters: empty Exclusive Waiters: 0xc6d76d80 (tid 100031, pid 31, "em0 taskq") Pending Threads: empty db> show turnstile 0xc7881140 Lock: 0xc0966b8c - (rw) tcp Lock Owner: 0xc6d76d80 (tid 100031, pid 31, "em0 taskq") Shared Waiters: 0xc6ca0000 (tid 100011, pid 19, "swi4: clock sio") 0xc7994d80 (tid 100192, pid 1833, "httpd") 0xc7883b40 (tid 100282, pid 1831, "httpd") 0xc7b1a000 (tid 100252, pid 1832, "httpd") Exclusive Waiters: 0xc6c9ab40 (tid 100013, pid 21, "swi1: net") 0xc7971000 (tid 100202, pid 1120, "nginx") 0xc7a04480 (tid 100204, pid 1122, "nginx") 0xc79a9000 (tid 100278, pid 1830, "httpd") Pending Threads: empty Unfortunately "show alllocks" output wasn't properly captured by textdump (as witness_list_lock() uses printf() for output, not db_printf() which is captured), but here is some reconstruction (lines from textdump's ddb.txt and msgbuf.txt, my memory about their relevant order): db> show alllocks Process 1319 (postgres) thread 0xc804a480 (100326) exclusive sx so_rcv_sx r = 0 (0xc7b088ac) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 1117 (sshd) thread 0xc708b240 (100057) exclusive sx so_rcv_sx r = 0 (0xc7b06a4c) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 956 (sshd) thread 0xc72476c0 (100119) exclusive sx so_rcv_sx r = 0 (0xc7d1bd8c) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 55 (g_mirror home) thread 0xc70c2d80 (100055) exclusive sx gmirror:lock r = 0 (0xc705442c) locked @ /usr/src/sys/modules/geom/geom_mirror/../../../geom/mirror/g_mirror.c:1858 Process 31 (em0 taskq) thread 0xc6d76d80 (100031) exclusive rw tcpinp r = 0 (0xc751d36c) locked @ /usr/src/sys/netinet/tcp_input.c:480 exclusive rw tcp r = 0 (0xc0966b8c) locked @ /usr/src/sys/netinet/tcp_input.c:400 Process 27 (swi6: Giant taskq) thread 0xc6ca06c0 (100027) exclusive sleep mutex Giant r = 0 (0xc0910630) locked @ /usr/src/sys/kern/kern_intr.c:1125 Process 19 (swi4: clock sio) thread 0xc6ca0000 (100011) shared rw PFil hook read/write mutex r = 0 (0xc0965e58) locked @ /usr/src/sys/net/pfil.c:73 exclusive sleep mutex tcp_sc_head r = 0 (0xc6fd7ac0) locked @ /usr/src/sys/kern/kern_timeout.c:241 The machine in question runs RELENG_7 from something about 2009-10-05. Please let me know if you need some more info. Maxim Dounin From rihad at mail.ru Thu Oct 8 05:23:42 2009 From: rihad at mail.ru (rihad) Date: Thu Oct 8 05:23:49 2009 Subject: Choosing two 10GiGE cards Message-ID: <4ACD775B.90901@mail.ru> Hi there, We think it's time to switch from two GiGE bce cards to 10GiGE. According to http://www.freebsd.org/releases/7.2R/hardware.html the 10GiGE cards listed below are supported on amd64. Anyone has personal experience using any of them them? Should I prefer drivers that support DEVICE_POLLING (actually, only ixgb as per "man polling")? I'll try to find out from the manufacturer how their own models differ from each other (all this LR/SR/CX4 stuff). Thanks. [i386,amd64] The ixgb(4) driver supports the following cards: * Intel PRO/10GbE LR Server Adapter * Intel PRO/10GbE SR Server Adapter [i386,amd64] The cxgb(4) driver supports 10 Gigabit and 1 Gigabit Ethernet adapters based on the T3 and T3B chipset: * Chelsio 10GBase-CX4 * Chelsio 10GBase-LR * Chelsio 10GBase-SR [i386,amd64] The mxge(4) driver supports 10 Gigabit Ethernet adapters based on the Myricom LANai Z8E chips: * Myricom 10GBase-CX4 (10G-PCIE-8A-C, 10G-PCIE-8AL-C) * Myricom 10GBase-R (10G-PCIE-8A-R, 10G-PCIE-8AL-R) * Myricom 10G XAUI over ribbon fiber (10G-PCIE-8A-Q, 10G-PCIE-8AL-Q) [i386,amd64] The nxge(4) driver supports Neterion Xframe 10 Gigabit Ethernet adapters listed in http://www.neterion.com/how/pricing.html. From andrew at modulus.org Thu Oct 8 05:29:07 2009 From: andrew at modulus.org (Andrew Snow) Date: Thu Oct 8 05:29:13 2009 Subject: Choosing two 10GiGE cards In-Reply-To: <4ACD775B.90901@mail.ru> References: <4ACD775B.90901@mail.ru> Message-ID: <4ACD781A.1030301@modulus.org> The only one worth getting IMO is Intel EXPX9502CX4 (INTEL 10 GIGABIT CX4 DUAL PORT SERVER ADAPTER) It is low power and very fast, and works under FreeBSD. Like all Intel NICs It supports interrupt modulation so polling support isn't really needed. - Andrew From rihad at mail.ru Thu Oct 8 05:35:51 2009 From: rihad at mail.ru (rihad) Date: Thu Oct 8 05:35:57 2009 Subject: Choosing two 10GiGE cards In-Reply-To: <4ACD781A.1030301@modulus.org> References: <4ACD775B.90901@mail.ru> <4ACD781A.1030301@modulus.org> Message-ID: <4ACD7A33.90308@mail.ru> Andrew Snow wrote: > > The only one worth getting IMO is Intel EXPX9502CX4 > (INTEL 10 GIGABIT CX4 DUAL PORT SERVER ADAPTER) > > It is low power and very fast, and works under FreeBSD. Like all Intel > NICs It supports interrupt modulation so polling support isn't really > needed. > > Thanks. What does DUAL PORT mean? It has two jacks? I think one such adapter will be more than enough to replace our two 1000 mbps cards, whether two jacks or not? From andrew at modulus.org Thu Oct 8 05:45:05 2009 From: andrew at modulus.org (Andrew Snow) Date: Thu Oct 8 05:45:12 2009 Subject: Choosing two 10GiGE cards In-Reply-To: <4ACD7A33.90308@mail.ru> References: <4ACD775B.90901@mail.ru> <4ACD781A.1030301@modulus.org> <4ACD7A33.90308@mail.ru> Message-ID: <4ACD7BD9.7000901@modulus.org> rihad wrote: >> The only one worth getting IMO is Intel EXPX9502CX4 >> (INTEL 10 GIGABIT CX4 DUAL PORT SERVER ADAPTER) > Thanks. What does DUAL PORT mean? It has two jacks? I think one such > adapter will be more than enough to replace our two 1000 mbps cards, > whether two jacks or not? Correct, it has two ports on the one card. It uses a PCIe x8 slot so plenty of bandwidth to serve two ports. - Andrew From siquijorphilips at gmail.com Thu Oct 8 05:50:03 2009 From: siquijorphilips at gmail.com (Siquijor Philips) Date: Thu Oct 8 05:50:10 2009 Subject: intel 82576 ipsec offload? Message-ID: Hi, I got a dual-port Intel Gigabit NIC with 82576 (ET) chipset http://www.intel.com/Assets/PDF/prodbrief/320116.pdf. It has a feature on IPsec offloading but it only mentioned Microsoft Windows 2008 and Vista servers. I wonder if FreeBSD have also support on this feature? Thanks, Siquijor From oleg at FreeBSD.org Thu Oct 8 06:06:10 2009 From: oleg at FreeBSD.org (Oleg Bulyzhin) Date: Thu Oct 8 06:06:17 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACCC4F3.3030302@mail.ru> References: <4AC8A76B.3050502@mail.ru> <20091007085902.GA88982@lath.rinet.ru> <4ACC5E23.8090405@mail.ru> <20091007100503.GB88982@lath.rinet.ru> <4ACC6A7B.5050808@mail.ru> <20091007104525.GC88982@lath.rinet.ru> <4ACC7308.6070301@mail.ru> <4ACCC30E.7080504@elischer.org> <4ACCC4F3.3030302@mail.ru> Message-ID: <20091008060608.GA23793@lath.rinet.ru> On Wed, Oct 07, 2009 at 09:42:27PM +0500, rihad wrote: > Julian Elischer wrote: > > rihad wrote: > >> Oleg Bulyzhin wrote: > > > >> You probably have some special sources of documentation ;-) According > >> to man ipfw, both "netgraph/ngtee" and "pipe" decide the fate of the > >> packet unless one_pass=0. Or do you mean sprinkling smart skiptos here > >> and there? ;-) > >> > > > > ngtee should not have any affect on the packet.. it takes a copy.. > > > That's a logical conclusion, although I prefer trusting the man at hand > (pun intended) if I haven't tested it myself to see how it works: > > ngtee cookie > A copy of packet is diverted into netgraph, original packet is > either accepted or continues with the next rule, depending on > net.inet.ip.fw.one_pass sysctl variable. See ng_ipfw(4) > for more > information on netgraph and ngtee actions. > > > Although... I've a question to Mr. Oleg: > > > 2) use 'tee' rule with ng_ksocket & ng_netflow > > tee port > Send a copy of packets matching this rule to the divert(4) > socket > bound to port port. The search continues with the next rule. > > how is it different from one_pass=0? Both tee and ngtee w/ one_pass=0 > continue with the next rule. tee & ngtee are similar with one_pass=0 and different with one_pass=1 -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From jfvogel at gmail.com Thu Oct 8 07:18:24 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Thu Oct 8 07:18:30 2009 Subject: Choosing two 10GiGE cards In-Reply-To: <4ACD7BD9.7000901@modulus.org> References: <4ACD775B.90901@mail.ru> <4ACD781A.1030301@modulus.org> <4ACD7A33.90308@mail.ru> <4ACD7BD9.7000901@modulus.org> Message-ID: <2a41acea0910080018w234261a7ud92a289298e5ad75@mail.gmail.com> If you really want to make the switch to 10G I would also seriously consider moving to FreeBSD 8, the changes that have been made in the stack will help you get the most out of the hardware. When it comes to Intel hardware the model Andrew cites is the CX4 version of the 82598, you can also get it in fiber. The next gen mac, 82599, is out, but I am not sure how easily they are obtainable in the channels yet. My ixgbe driver supports both, the 599 will have some advantages, I am just about ready to release the latest driver that will now have Hardware LRO among other enhancements. I believe Dell and Supermicro will, or already have i7 servers with a couple of these as LOMs. Thanks for the plug btw Andrew! Jack On Wed, Oct 7, 2009 at 10:42 PM, Andrew Snow wrote: > rihad wrote: > >> The only one worth getting IMO is Intel EXPX9502CX4 >>> (INTEL 10 GIGABIT CX4 DUAL PORT SERVER ADAPTER) >>> >> > Thanks. What does DUAL PORT mean? It has two jacks? I think one such >> adapter will be more than enough to replace our two 1000 mbps cards, whether >> two jacks or not? >> > > Correct, it has two ports on the one card. It uses a PCIe x8 slot so plenty > of bandwidth to serve two ports. > > - Andrew > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From smithi at nimnet.asn.au Thu Oct 8 11:39:49 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Thu Oct 8 11:39:56 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACCA92A.9070803@mail.ru> References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> <4ACC5563.602@mail.ru> <4ACC56A6.1030808@mail.ru> <4ACC5DEC.1010006@mail.ru> <4ACC65A0.7030900@mail.ru> <4ACC8CC8.8050403@mail.ru> <4ACCA92A.9070803@mail.ru> Message-ID: <20091008212623.D88524@sola.nimnet.asn.au> On Wed, 7 Oct 2009, rihad wrote: > Robert Watson wrote: > > > I would suggest making just the HZ -> 4000 change for now and see how it > > goes. > > > OK, I will try testing HZ=4000 tomorrow morning, although I'm pretty sure > there still will be some drops. Even if there are, I'd like to know what (rough) percentage in increased interrupt load you experience with HZ=4000 vs 1000 on that beast in your application, or of any discernable effects on other running processes? [Thanks guys for this interesting thread] > > > Can someone please say how to increase the "ifnet transmit queue sizes"? > > > > Unfortunately, I fear that this is driver-specific, and in the case of bce > > requires a recompile. In the driver init code in if_bce, the following > > code appears: > > > > ifp->if_snd.ifq_drv_maxlen = USABLE_TX_BD; > > IFQ_SET_MAXLEN(&ifp->if_snd, ifp->if_snd.ifq_drv_maxlen); > > IFQ_SET_READY(&ifp->if_snd); > > > > Which evaluates to a architecture-specific value due to varying pagesize. > > You might just try forcing it to 1024. > > > I think I'll try this too, if HZ=4000 doesn't help, thanks a lot. > In the long run we'll switch to some high-quality 10 GiGE cards. From rihad at mail.ru Thu Oct 8 12:14:08 2009 From: rihad at mail.ru (rihad) Date: Thu Oct 8 12:14:21 2009 Subject: dummynet dropping too many packets In-Reply-To: References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> <4ACC5563.602@mail.ru> <4ACC56A6.1030808@mail.ru> <4ACC5DEC.1010006@mail.ru> <4ACC65A0.7030900@mail.ru> <4ACC8CC8.8050403@mail.ru> Message-ID: <4ACDD789.8030804@mail.ru> Robert Watson wrote: > I would suggest making just the HZ -> 4000 change for now and see how it > goes. > Been running for a few hours under these changed sysctls: kern.clockrate: { hz = 4000, tick = 250, profhz = 4000, stathz = 129 } net.inet.ip.dummynet.io_fast: 1 net.inet.ip.dummynet.hash_size: 512 net.isr.direct: 0 net.inet.ip.intr_queue_maxlen: 5000 kern.ipc.nmbclusters=111111 Current stats: net.inet.ip.dummynet.search_steps: 190347891 net.inet.ip.dummynet.searches: 188979871 net.inet.ip.dummynet.io_pkt_drop: 0 net.inet.ip.intr_queue_drops: 0 Around 1800 entries in each of the two ipfw tables. About 420 mbps of traffic passing through. ipfw pipe's created with GRED queuing algorithm, if it matters: ipfw pipe 64 config bw 64kbit/s mask dst-ip 0xffffffff gred 0.002/1800/2000/0.1 queue 2000 etc. 0 global output packet drops per second. top -SH: last pid: 59120; load averages: 0.87, 1.19, 1.27 up 0+04:31:38 17:11:59 141 processes: 9 running, 115 sleeping, 17 waiting CPU: 3.8% user, 0.0% nice, 3.0% system, 8.8% interrupt, 84.4% idle Mem: 1302M Active, 1482M Inact, 350M Wired, 40K Cache, 214M Buf, 801M Free Swap: 2048M Total, 2048M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 16 root 171 ki31 0K 16K CPU2 2 237:10 97.02% idle: cpu2 14 root 171 ki31 0K 16K CPU4 4 225:33 96.48% idle: cpu4 12 root 171 ki31 0K 16K CPU6 6 249:31 88.96% idle: cpu6 15 root 171 ki31 0K 16K CPU3 3 224:18 88.92% idle: cpu3 13 root 171 ki31 0K 16K CPU5 5 228:39 87.74% idle: cpu5 11 root 171 ki31 0K 16K CPU7 7 235:02 87.35% idle: cpu7 18 root 171 ki31 0K 16K RUN 0 198:11 81.98% idle: cpu0 17 root 171 ki31 0K 16K CPU1 1 209:31 71.78% idle: cpu1 21 root -44 - 0K 16K WAIT 0 88:24 47.31% swi1: net 29 root -68 - 0K 16K WAIT 1 34:06 18.95% irq256: bce0 470 root -68 - 0K 16K - 7 21:24 6.01% dummynet 19 root -32 - 0K 16K WAIT 5 13:37 5.86% swi4: clock sio 31 root -68 - 0K 16K WAIT 2 7:45 4.44% irq257: bce1 I'll wait for the number of entries to reach 2000-2200 or so, and post back again. From rihad at mail.ru Thu Oct 8 12:58:39 2009 From: rihad at mail.ru (rihad) Date: Thu Oct 8 12:58:46 2009 Subject: dummynet dropping too many packets In-Reply-To: References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> <4ACC5563.602@mail.ru> <4ACC56A6.1030808@mail.ru> <4ACC5DEC.1010006@mail.ru> <4ACC65A0.7030900@mail.ru> <4ACC8CC8.8050403@mail.ru> Message-ID: <4ACDE1FB.6020602@mail.ru> Robert Watson wrote: > I would suggest making just the HZ -> 4000 change for now and see how > it goes. > 2018 users online, 73 drops have just occurred. p.s.: already 123 drops. It will only get worse after some time. Traffic load: 440-450 mbps. top -HS: last pid: 68314; load averages: 1.35, 1.22, 1.25 up 0+05:13:28 17:53:49 145 processes: 11 running, 118 sleeping, 16 waiting CPU: 1.4% user, 0.0% nice, 2.8% system, 10.3% interrupt, 85.5% idle Mem: 1337M Active, 1683M Inact, 355M Wired, 40K Cache, 214M Buf, 560M Free Swap: 2048M Total, 2048M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 14 root 171 ki31 0K 16K CPU4 4 257:35 99.41% idle: cpu4 12 root 171 ki31 0K 16K RUN 6 286:39 98.14% idle: cpu6 18 root 171 ki31 0K 16K RUN 0 225:16 92.72% idle: cpu0 15 root 171 ki31 0K 16K RUN 3 255:35 90.04% idle: cpu3 16 root 171 ki31 0K 16K CPU2 2 272:04 87.40% idle: cpu2 13 root 171 ki31 0K 16K CPU5 5 260:52 81.69% idle: cpu5 17 root 171 ki31 0K 16K CPU1 1 239:06 75.29% idle: cpu1 21 root -44 - 0K 16K CPU7 7 108:49 57.37% swi1: net 11 root 171 ki31 0K 16K CPU7 7 267:48 49.02% idle: cpu7 29 root -68 - 0K 16K WAIT 1 41:45 20.90% irq256: bce0 470 root -68 - 0K 16K - 5 27:01 9.18% dummynet 19 root -32 - 0K 16K WAIT 1 16:13 6.59% swi4: clock sio 31 root -68 - 0K 16K WAIT 2 9:35 4.35% irq257: bce1 > Robert Watson wrote: > Suggestions like increasing timer resolution are intended to spread > out the injection of packets by dummynet to attempt to reduce the > peaks of burstiness that occur when multiple queues inject packets in > a burst that exceeds the queue depth supported by combined hardware > descriptor rings and software transmit queue. How to tweak the software transmit queue? P.S.: still only 123 drops (while io_pkt_drop: 0, intr_queue_drops: 0), but it was a warning. From rihad at mail.ru Thu Oct 8 15:32:54 2009 From: rihad at mail.ru (rihad) Date: Thu Oct 8 15:33:00 2009 Subject: dummynet dropping too many packets In-Reply-To: References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> <4ACC5563.602@mail.ru> <4ACC56A6.1030808@mail.ru> <4ACC5DEC.1010006@mail.ru> <4ACC65A0.7030900@mail.ru> <4ACC8CC8.8050403@mail.ru> Message-ID: <4ACE061E.4010807@mail.ru> Robert Watson wrote: > I would suggest making just the HZ -> 4000 change for now and see how > it goes. > ~4000 online users, ~450-470 mbps traffic, 300-600 global drops per second. Same ole. Not funny at all. net.inet.ip.dummynet.io_pkt_drop: 0 net.inet.ip.intr_queue_drops: 0 net.inet.ip.fastforwarding: 1 > Robert Watson wrote: > Suggestions like increasing timer resolution are intended to spread > out the injection of packets by dummynet to attempt to reduce the > peaks of burstiness that occur when multiple queues inject packets in > a burst that exceeds the queue depth supported by combined hardware > descriptor rings and software transmit queue. My last chance is to tweak the software transmit queue. Just how can I alter its size? P.S.: We're definitely going to buy a 10GigE card. Like this one: http://cgi.ebay.com/EXPX9502CX4-10-CX4-DualPort-Svr-Adap-Intel-Corp_W0QQitemZ150358746205QQcmdZViewItemQQptZLH_DefaultDomain_0?hash=item230214645d From rihad at mail.ru Thu Oct 8 15:42:42 2009 From: rihad at mail.ru (rihad) Date: Thu Oct 8 15:42:49 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091008212623.D88524@sola.nimnet.asn.au> References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> <4ACC5563.602@mail.ru> <4ACC56A6.1030808@mail.ru> <4ACC5DEC.1010006@mail.ru> <4ACC65A0.7030900@mail.ru> <4ACC8CC8.8050403@mail.ru> <4ACCA92A.9070803@mail.ru> <20091008212623.D88524@sola.nimnet.asn.au> Message-ID: <4ACE086C.2020308@mail.ru> Ian Smith wrote: > On Wed, 7 Oct 2009, rihad wrote: > > > Robert Watson wrote: > > > > > I would suggest making just the HZ -> 4000 change for now and see how it > > > goes. > > > > > OK, I will try testing HZ=4000 tomorrow morning, although I'm pretty sure > > there still will be some drops. > > Even if there are, I'd like to know what (rough) percentage in increased > interrupt load you experience with HZ=4000 vs 1000 on that beast in your > application, or of any discernable effects on other running processes? > Besides having little (if any) positive effect on the output packet drop rate, it runs pretty well, there's no apparent difference, no drop in performance etc. Current interrupt load snapshot as per systat -vmstat: Interrupts 59606 total atkbd0 1 ata0 irq14 931 mfi0 irq16 uhci0 uhci 4001 cpu0: time 23549 bce0 256 3118 bce1 257 3999 cpu3: time 3999 cpu2: time 4001 cpu1: time 4003 cpu4: time 4003 cpu5: time 4001 cpu6: time 4001 cpu7: time From julian at elischer.org Thu Oct 8 16:45:02 2009 From: julian at elischer.org (Julian Elischer) Date: Thu Oct 8 16:45:10 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091008060608.GA23793@lath.rinet.ru> References: <4AC8A76B.3050502@mail.ru> <20091007085902.GA88982@lath.rinet.ru> <4ACC5E23.8090405@mail.ru> <20091007100503.GB88982@lath.rinet.ru> <4ACC6A7B.5050808@mail.ru> <20091007104525.GC88982@lath.rinet.ru> <4ACC7308.6070301@mail.ru> <4ACCC30E.7080504@elischer.org> <4ACCC4F3.3030302@mail.ru> <20091008060608.GA23793@lath.rinet.ru> Message-ID: <4ACE10CF.2030806@elischer.org> Oleg Bulyzhin wrote: > On Wed, Oct 07, 2009 at 09:42:27PM +0500, rihad wrote: >> Julian Elischer wrote: >>> rihad wrote: >>>> Oleg Bulyzhin wrote: >>>> You probably have some special sources of documentation ;-) According >>>> to man ipfw, both "netgraph/ngtee" and "pipe" decide the fate of the >>>> packet unless one_pass=0. Or do you mean sprinkling smart skiptos here >>>> and there? ;-) >>>> >>> ngtee should not have any affect on the packet.. it takes a copy.. >>> >> That's a logical conclusion, although I prefer trusting the man at hand >> (pun intended) if I haven't tested it myself to see how it works: >> >> ngtee cookie >> A copy of packet is diverted into netgraph, original packet is >> either accepted or continues with the next rule, depending on >> net.inet.ip.fw.one_pass sysctl variable. See ng_ipfw(4) >> for more >> information on netgraph and ngtee actions. >> >> >> Although... I've a question to Mr. Oleg: >> >>> 2) use 'tee' rule with ng_ksocket & ng_netflow >> tee port >> Send a copy of packets matching this rule to the divert(4) >> socket >> bound to port port. The search continues with the next rule. >> >> how is it different from one_pass=0? Both tee and ngtee w/ one_pass=0 >> continue with the next rule. > > tee & ngtee are similar with one_pass=0 and different with one_pass=1 that seems like a bug to me.. neither tee should ever terminate a search. if you want to terminate it, add a specific rule to do so. Unfortunately I wasn't involved in writing it. From julian at elischer.org Thu Oct 8 16:45:17 2009 From: julian at elischer.org (Julian Elischer) Date: Thu Oct 8 16:45:23 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACDE1FB.6020602@mail.ru> References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> <4ACC5563.602@mail.ru> <4ACC56A6.1030808@mail.ru> <4ACC5DEC.1010006@mail.ru> <4ACC65A0.7030900@mail.ru> <4ACC8CC8.8050403@mail.ru> <4ACDE1FB.6020602@mail.ru> Message-ID: <4ACE171D.9080707@elischer.org> rihad wrote: > Robert Watson wrote: >> I would suggest making just the HZ -> 4000 change for now and see how >> it goes. >> > 2018 users online, 73 drops have just occurred. > p.s.: already 123 drops. > It will only get worse after some time. > > Traffic load: 440-450 mbps. > > top -HS: > last pid: 68314; load averages: 1.35, 1.22, 1.25 > up 0+05:13:28 17:53:49 > 145 processes: 11 running, 118 sleeping, 16 waiting > CPU: 1.4% user, 0.0% nice, 2.8% system, 10.3% interrupt, 85.5% idle > Mem: 1337M Active, 1683M Inact, 355M Wired, 40K Cache, 214M Buf, 560M Free > Swap: 2048M Total, 2048M Free > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 14 root 171 ki31 0K 16K CPU4 4 257:35 99.41% idle: cpu4 > 12 root 171 ki31 0K 16K RUN 6 286:39 98.14% idle: cpu6 > 18 root 171 ki31 0K 16K RUN 0 225:16 92.72% idle: cpu0 > 15 root 171 ki31 0K 16K RUN 3 255:35 90.04% idle: cpu3 > 16 root 171 ki31 0K 16K CPU2 2 272:04 87.40% idle: cpu2 > 13 root 171 ki31 0K 16K CPU5 5 260:52 81.69% idle: cpu5 > 17 root 171 ki31 0K 16K CPU1 1 239:06 75.29% idle: cpu1 > 21 root -44 - 0K 16K CPU7 7 108:49 57.37% swi1: net > 11 root 171 ki31 0K 16K CPU7 7 267:48 49.02% idle: cpu7 > 29 root -68 - 0K 16K WAIT 1 41:45 20.90% irq256: bce0 > 470 root -68 - 0K 16K - 5 27:01 9.18% dummynet > 19 root -32 - 0K 16K WAIT 1 16:13 6.59% swi4: > clock sio > 31 root -68 - 0K 16K WAIT 2 9:35 4.35% irq257: bce1 > >> Robert Watson wrote: >> Suggestions like increasing timer resolution are intended to spread >> out the injection of packets by dummynet to attempt to reduce the >> peaks of burstiness that occur when multiple queues inject packets in >> a burst that exceeds the queue depth supported by combined hardware >> descriptor rings and software transmit queue. > > How to tweak the software transmit queue? > > > P.S.: still only 123 drops (while io_pkt_drop: 0, intr_queue_drops: 0), > but it was a warning. you can not do anything about it if one of the custommers sends a burst of 3000 udp packets at their maximum speed(or maybe some combination of custommers to something which results in an aggreagate burst rate like that. In other words you may always continue to get moments when the pipe releases a bunch of stuff that has a potential to over-run something down stream. Think of it as a dam in a stream... If you have no dam, teh water level goes up and down gradually and by small amounts, but if you have a dam, you can release water in such a way that the stream is flooded higher than it would normally ever get. work out how large a burst of data the pipe will release in 1/4000th of a second and using a small packet size, work out how many packets that is. Then make sure that the driver software input queue is capable of holding that many packets. From rihad at mail.ru Thu Oct 8 16:54:47 2009 From: rihad at mail.ru (rihad) Date: Thu Oct 8 16:54:55 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACE10CF.2030806@elischer.org> References: <4AC8A76B.3050502@mail.ru> <20091007085902.GA88982@lath.rinet.ru> <4ACC5E23.8090405@mail.ru> <20091007100503.GB88982@lath.rinet.ru> <4ACC6A7B.5050808@mail.ru> <20091007104525.GC88982@lath.rinet.ru> <4ACC7308.6070301@mail.ru> <4ACCC30E.7080504@elischer.org> <4ACCC4F3.3030302@mail.ru> <20091008060608.GA23793@lath.rinet.ru> <4ACE10CF.2030806@elischer.org> Message-ID: <4ACE194F.6030601@mail.ru> Julian Elischer wrote: >> tee & ngtee are similar with one_pass=0 and different with one_pass=1 > > that seems like a bug to me.. > neither tee should ever terminate a search. > > if you want to terminate it, add a specific rule to do so. > Unfortunately I wasn't involved in writing it. > > +1 ngtee shouldn't terminate the search, i.e. behave exactly that way tee does. From rihad at mail.ru Thu Oct 8 17:05:37 2009 From: rihad at mail.ru (rihad) Date: Thu Oct 8 17:05:44 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACE171D.9080707@elischer.org> References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> <4ACC5563.602@mail.ru> <4ACC56A6.1030808@mail.ru> <4ACC5DEC.1010006@mail.ru> <4ACC65A0.7030900@mail.ru> <4ACC8CC8.8050403@mail.ru> <4ACDE1FB.6020602@mail.ru> <4ACE171D.9080707@elischer.org> Message-ID: <4ACE1B95.2090508@mail.ru> Julian Elischer wrote: > you can not do anything about it if one of the custommers sends a burst > of 3000 udp packets at their maximum speed(or maybe some combination of > custommers to something which results in an aggreagate burst rate like > that. > In other words you may always continue to get moments when the pipe > releases a bunch of stuff that has a potential to over-run something > down stream. > I've said this before, but: the PC is only dealing with the downstream traffic, i.e. traffic arriving from the net. I won't say anything against dummynet bursts overfilling hardware buffers, but they're _only_taking place when the number of entries in the ipfw tables reaches 2000 or so, and the traffic load is at about 430-450 mbps. That is, it _never_ happens before both conditions are true. Although raising HZ from 1000 up to 4000 hasn't helped, which is somewhat contrary to the idea of bursts. My idea is to switch to an Intel 10GigE card, which is unavoidable sooner or later anyway, given our natural growth. Probably an upgrade to 8.0 will do some good, too. > Think of it as a dam in a stream... > > If you have no dam, teh water level goes up and down gradually and by > small amounts, but if you have a dam, you can release water in such a > way that the stream is flooded higher than it would normally ever get. > > > work out how large a burst of data the pipe will release in 1/4000th of > a second and using a small packet size, work out how many packets that > is. Then make sure that the driver software input queue is > capable of holding that many packets. > > From pyunyh at gmail.com Thu Oct 8 17:46:40 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Oct 8 17:46:50 2009 Subject: intel 82576 ipsec offload? In-Reply-To: References: Message-ID: <20091008174521.GE3843@michelle.cdnetworks.com> On Thu, Oct 08, 2009 at 01:24:20PM +0800, Siquijor Philips wrote: > Hi, > > I got a dual-port Intel Gigabit NIC with 82576 (ET) chipset > http://www.intel.com/Assets/PDF/prodbrief/320116.pdf. It has a feature > on IPsec offloading but it only mentioned Microsoft Windows 2008 and > Vista servers. I wonder if FreeBSD have also support on this feature? > AFAIK it's not yet, not sure whether Jack has plan to implement the offloading. I know old Intel i82550 also supported IPSec offloading but Intel didn't release required information to implement it. 3Com also supported IPSec offloading in their 3XP hardwares(txp(4)) but the offloading was not implemented. > Thanks, > Siquijor From stef-list at memberwebs.com Fri Oct 9 01:35:39 2009 From: stef-list at memberwebs.com (Stef Walter) Date: Fri Oct 9 01:35:46 2009 Subject: Unbreak setfib + routing daemon [patch roundup] Message-ID: <4ACE9367.2050909@memberwebs.com> I've been running the attached patch for a month on routers in production. To summarize: * Routing daemons listen to routing messages. * Without the patch routing messages all FIBs are sent to all listeners. * Routing daemons get confused. This patch makes routing daemons listening to routing messages only receive those that affect their FIB. Some routing messages (such as interface address announcements etc..) are still sent to all listeners. Patches attached for CURRENT, latest 8.0, and 7.2. Previous discussion: http://www.mail-archive.com/freebsd-net@freebsd.org/msg30815.html PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134931 Cheers, Stef -------------- next part -------------- A non-text attachment was scrubbed... Name: freebsd8-route-messages-respect-fib-2.patch Type: text/x-diff Size: 8029 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20091009/b0fcc537/freebsd8-route-messages-respect-fib-2.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: freebsd9-route-messages-respect-fib-2.patch Type: text/x-diff Size: 8029 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20091009/b0fcc537/freebsd9-route-messages-respect-fib-2.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: freebsd72-route-messages-respect-fib-2.patch Type: text/x-diff Size: 7488 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20091009/b0fcc537/freebsd72-route-messages-respect-fib-2.bin From siquijorphilips at gmail.com Fri Oct 9 04:14:15 2009 From: siquijorphilips at gmail.com (Siquijor Philips) Date: Fri Oct 9 04:14:21 2009 Subject: intel 82576 ipsec offload? In-Reply-To: <20091008174521.GE3843@michelle.cdnetworks.com> References: <20091008174521.GE3843@michelle.cdnetworks.com> Message-ID: On Fri, Oct 9, 2009 at 1:45 AM, Pyun YongHyeon wrote: > On Thu, Oct 08, 2009 at 01:24:20PM +0800, Siquijor Philips wrote: >> Hi, >> >> I got a dual-port Intel Gigabit NIC with 82576 (ET) chipset >> http://www.intel.com/Assets/PDF/prodbrief/320116.pdf. It has a feature >> on IPsec offloading but it only mentioned Microsoft Windows 2008 and >> Vista servers. I wonder if FreeBSD have also support on this feature? >> > > AFAIK it's not yet, not sure whether Jack has plan to implement the > offloading. I know old Intel i82550 also supported IPSec offloading > but Intel didn't release required information to implement it. 3Com > also supported IPSec offloading in their 3XP hardwares(txp(4)) but > the offloading was not implemented. > Hi Pyun, Thanks for your info! By the way, who is Jack? Is he the author of this driver? I really need to have this feature usable on the driver. I bought these NICs with 82576 chipset for the purpose of implementing IPsec in my network and my current FreeBSD servers could benefit it. Just really thought it has support because FreeBSD was already part of the supported operating system. I was alerted when I've re-read the product info document again that it only support Windows 2008 and Vista platforms. Now, I've confirmed that with the current existing driver. I hope this guy has the plan of implementing it sooner because I really need it. Thanks, Siquijor From bennett at cs.niu.edu Fri Oct 9 07:21:38 2009 From: bennett at cs.niu.edu (Scott Bennett) Date: Fri Oct 9 07:21:44 2009 Subject: dummynet dropping too many packets Message-ID: <200910090622.n996MwJV015692@mp.cs.niu.edu> On Wed, 07 Oct 2009 20:02:21 +0500 rihad wrote: >Ingo Flaschberger wrote: >> Hi, >> >> can you send me the dmesg ouput from your networkcards when they are >> detected at booting? >> >Hello, > >bce0: mem >0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci7 >bce0: Ethernet address: 00:1d:09:xx:xx:xx >bce0: [ITHREAD] >bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W >(0x03050C05); Flags( MFW MSI ) >bce1: mem >0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci3 >bce1: Ethernet address: 00:1d:09:xx:xx:xx >bce1: [ITHREAD] >bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W >(0x03050C05); Flags( MFW MSI ) > > >> can you also send me a lspci and lspci -v ? >> >Sorry, this is FreeBSD, not Linux ;-) > Try sysutils/pciutils in ports. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * ********************************************************************** From oleg at FreeBSD.org Fri Oct 9 08:27:44 2009 From: oleg at FreeBSD.org (Oleg Bulyzhin) Date: Fri Oct 9 08:27:51 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACE10CF.2030806@elischer.org> References: <20091007085902.GA88982@lath.rinet.ru> <4ACC5E23.8090405@mail.ru> <20091007100503.GB88982@lath.rinet.ru> <4ACC6A7B.5050808@mail.ru> <20091007104525.GC88982@lath.rinet.ru> <4ACC7308.6070301@mail.ru> <4ACCC30E.7080504@elischer.org> <4ACCC4F3.3030302@mail.ru> <20091008060608.GA23793@lath.rinet.ru> <4ACE10CF.2030806@elischer.org> Message-ID: <20091009082743.GB70940@lath.rinet.ru> On Thu, Oct 08, 2009 at 09:18:23AM -0700, Julian Elischer wrote: > that seems like a bug to me.. > neither tee should ever terminate a search. agree. But documented bug is a feature ;) and i'm not sure if we fix this wouldnt it break POLA? > > if you want to terminate it, add a specific rule to do so. > Unfortunately I wasn't involved in writing it. ip_fw_pfil.c: revision 1.17 date: 2005/02/05 12:06:33; author: glebius; state: Exp; lines: +47 -0 Add a ng_ipfw node, implementing a quick and simple interface between ipfw(4) and netgraph(4) facilities. Reviewed by: andre, brooks, julian ^^^^^^ -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From jacques.fourie at gmail.com Fri Oct 9 09:15:53 2009 From: jacques.fourie at gmail.com (Jacques Fourie) Date: Fri Oct 9 09:16:00 2009 Subject: Route re-calculation in ip_output() Message-ID: Hi, I've noticed what I believe to be a bug in ip_output(). The piece of code in question is when the firewall changes the destination address of an outgoing packet and the subsequent re-calculation of the route. The issue should be clear from the attached diff - basically what happens is that for the second route lookup dst can point to ro->ro_rt->rt_gateway instead of &ro->ro_dst. It seems as if this issue is present on 7,8 and 9? --- ip_output.c 2009-10-09 10:37:40.537408240 +0200 +++ /home/jacques/ip_output.c 2009-10-09 10:43:46.232819440 +0200 @@ -521,8 +521,10 @@ #endif error = netisr_queue(NETISR_IP, m); goto done; - } else + } else { + dst = (struct sockaddr_in *)&ro->ro_dst; goto again; /* Redo the routing table lookup. */ + } Regards, Jacques From rihad at mail.ru Fri Oct 9 14:35:12 2009 From: rihad at mail.ru (rihad) Date: Fri Oct 9 14:35:19 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091007115425.GD88982@lath.rinet.ru> References: <4AC8A76B.3050502@mail.ru> <20091007085902.GA88982@lath.rinet.ru> <4ACC5E23.8090405@mail.ru> <20091007100503.GB88982@lath.rinet.ru> <4ACC6A7B.5050808@mail.ru> <20091007104525.GC88982@lath.rinet.ru> <4ACC7308.6070301@mail.ru> <20091007115425.GD88982@lath.rinet.ru> Message-ID: <4ACF4A15.1010203@mail.ru> Oleg Bulyzhin wrote: > On Wed, Oct 07, 2009 at 03:52:56PM +0500, rihad wrote: > >> You probably have some special sources of documentation ;-) According to >> man ipfw, both "netgraph/ngtee" and "pipe" decide the fate of the packet >> unless one_pass=0. Or do you mean sprinkling smart skiptos here and >> there? ;-) > > you can > 1) use ng_ether & ng_netflow. (so no need in 'ngtee' rule). > 2) use 'tee' rule with ng_ksocket & ng_netflow > >>> Could you show your 'ipfw show' output? (hide ip addresses if you wish but >>> keep counters please). >>> > >> Here it is, in its whole glory: >> >> 00100 10434423 1484891105 allow ip from any to any via lo0 >> 00200 2 14 deny ip from any to 127.0.0.0/8 >> 00300 1 4 deny ip from 127.0.0.0/8 to any >> 01000 3300039938 327603104711 allow ip from any to any in >> 01010 26214900 421138433 allow ip from me to any out >> 01020 5453857 46806278 allow icmp from any to any out >> 01030 3268289053 327224694165 ngtee 1 ip from any to any out >> 01040 18681181 1089636054 skipto 1100 ip from table(127) to any out >> recv bce0 xmit bce1 >> 01060 777488848 76743392754 pipe tablearg ip from any to table(0) out >> recv bce0 xmit bce1 >> 01070 776831109 76682499457 allow ip from any to table(0) out recv >> bce0 xmit bce1 >> 01100 13102697 808411842 pipe tablearg ip from any to table(2) out >> 65535 662648946 66711487830 allow ip from any to any > > I guess this one would be better(faster): > > 00050 allow ip from any to any in > 00100 allow ip from any to any via lo0 > 01010 allow ip from me to any > 01020 allow icmp from any to any > 01030 ngtee 1 ip from any to any > 01035 skipto 1040 ip from any to any recv bce0 xmit bce1 > 01036 allow ip from any to any > 01040 skipto 1100 ip from table(127) to any > 01060 pipe tablearg ip from any to table(0) > 01070 allow ip from any to any > 01100 pipe tablearg ip from any to table(2) > 65535 allow ip from any to any > Tried it just now - no visible effect. 400-700 packet drops per second which is around 5-7 mbps dropped on output. So I don't think getting rid of one_pass=0 would help at all. From julian at elischer.org Fri Oct 9 15:58:27 2009 From: julian at elischer.org (Julian Elischer) Date: Fri Oct 9 15:58:34 2009 Subject: Route re-calculation in ip_output() In-Reply-To: References: Message-ID: <4ACF5DA5.6060806@elischer.org> Jacques Fourie wrote: > Hi, > > I've noticed what I believe to be a bug in ip_output(). The piece of > code in question is when the firewall changes the destination address > of an outgoing packet and the subsequent re-calculation of the route. > The issue should be clear from the attached diff - basically what > happens is that for the second route lookup dst can point to > ro->ro_rt->rt_gateway instead of &ro->ro_dst. It seems as if this > issue is present on 7,8 and 9? Is this a problem? generally, the aim of a fwd firewall rule is to set the next hop (gateway). so this may be what is required.. > > --- ip_output.c 2009-10-09 10:37:40.537408240 +0200 > +++ /home/jacques/ip_output.c 2009-10-09 10:43:46.232819440 +0200 > @@ -521,8 +521,10 @@ > #endif > error = netisr_queue(NETISR_IP, m); > goto done; > - } else > + } else { > + dst = (struct sockaddr_in *)&ro->ro_dst; > goto again; /* Redo the routing table lookup. */ > + } > > > Regards, > Jacques > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From freebsd at optiksecurite.com Fri Oct 9 16:24:34 2009 From: freebsd at optiksecurite.com (Martin Turgeon) Date: Fri Oct 9 16:24:41 2009 Subject: How can I get >100 connections in FIN_WAIT_2 state from the same IP? Message-ID: <4ACF5597.5000107@optiksecurite.com> Hi everyone, I would like to know if anyone knows the reason why I get a lot of connections (more than 100) from the same IP in FIN_WAIT_2 state. Refering to this diagram (http://www.jxos.org/Projects/TCP/tcpstate.html), the connection enter in FIN_WAIT_1 when the server closes the connection and in FIN_WAIT_2 when the client ACK the FIN from the server. For the connection to stay in FIN_WAIT_2, the client must never send his FIN, right? In this case the connections are on port 80. Is it a problem with the client's browser or OS? Is it possible that some mobile devices doesn't close their connections correctly to save bandwidth and battery? I know this isn't specific to FreeBSD, but thanks for your answer anyway Martin From Lutz.Bichler at gmx.de Fri Oct 9 17:35:22 2009 From: Lutz.Bichler at gmx.de (Lutz Bichler) Date: Fri Oct 9 17:35:28 2009 Subject: Intel WiFi 5100/5300 Message-ID: <20091009170839.142800@gmx.net> Hi, does anybody know what happened to the attempts to support Intel WiFi 5100/5300 interfaces in the iwn-driver? Are any patches available which could be used to start working on support for these interfaces? Lutz -- GRATIS f?r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 From jfvogel at gmail.com Fri Oct 9 18:17:02 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Fri Oct 9 18:17:08 2009 Subject: intel 82576 ipsec offload? In-Reply-To: References: <20091008174521.GE3843@michelle.cdnetworks.com> Message-ID: <2a41acea0910091117q6cfab252sa8d5dfcf0182b660@mail.gmail.com> I am Jack, the network engineer at Intel responsible for all FreeBSD wired lan drivers. This is the first I've seen about this. Our understanding was that the infrastructure needed to do IPSec was not available for either Linux or FreeBSD, can you please explain things? If everything is there except the support in the driver then I might be able to add that to my queue. Cheers, Jack On Thu, Oct 8, 2009 at 9:14 PM, Siquijor Philips wrote: > On Fri, Oct 9, 2009 at 1:45 AM, Pyun YongHyeon wrote: > > On Thu, Oct 08, 2009 at 01:24:20PM +0800, Siquijor Philips wrote: > >> Hi, > >> > >> I got a dual-port Intel Gigabit NIC with 82576 (ET) chipset > >> http://www.intel.com/Assets/PDF/prodbrief/320116.pdf. It has a feature > >> on IPsec offloading but it only mentioned Microsoft Windows 2008 and > >> Vista servers. I wonder if FreeBSD have also support on this feature? > >> > > > > AFAIK it's not yet, not sure whether Jack has plan to implement the > > offloading. I know old Intel i82550 also supported IPSec offloading > > but Intel didn't release required information to implement it. 3Com > > also supported IPSec offloading in their 3XP hardwares(txp(4)) but > > the offloading was not implemented. > > > > Hi Pyun, > > Thanks for your info! By the way, who is Jack? Is he the author of > this driver? I really need to have this feature usable on the driver. > I bought these NICs with 82576 chipset for the purpose of implementing > IPsec in my network and my current FreeBSD servers could benefit it. > Just really thought it has support because FreeBSD was already part of > the supported operating system. I was alerted when I've re-read the > product info document again that it only support Windows 2008 and > Vista platforms. Now, I've confirmed that with the current existing > driver. I hope this guy has the plan of implementing it sooner because > I really need it. > > Thanks, > Siquijor > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From bschmidt at techwires.net Fri Oct 9 18:28:12 2009 From: bschmidt at techwires.net (Bernhard Schmidt) Date: Fri Oct 9 18:28:19 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <20091009170839.142800@gmx.net> References: <20091009170839.142800@gmx.net> Message-ID: <200910092003.57367.bschmidt@techwires.net> On Friday 09 October 2009 19:08:39 Lutz Bichler wrote: > Hi, > > does anybody know what happened to the attempts to support Intel WiFi > 5100/5300 interfaces in the iwn-driver? Are any patches available which > could be used to start working on support for these interfaces? I'm curious too, as I'm playing with idea to start porting the latest changes to if_iwn from OpenBSD. Already started with adding the 5000 series firmware to iwnfw... -- Bernhard From julian at elischer.org Fri Oct 9 18:47:34 2009 From: julian at elischer.org (Julian Elischer) Date: Fri Oct 9 18:47:42 2009 Subject: intel 82576 ipsec offload? In-Reply-To: <2a41acea0910091117q6cfab252sa8d5dfcf0182b660@mail.gmail.com> References: <20091008174521.GE3843@michelle.cdnetworks.com> <2a41acea0910091117q6cfab252sa8d5dfcf0182b660@mail.gmail.com> Message-ID: <4ACF8548.8090309@elischer.org> Jack Vogel wrote: > I am Jack, the network engineer at Intel responsible for all FreeBSD wired > lan drivers. > This is the first I've seen about this. Our understanding was that the > infrastructure needed > to do IPSec was not available for either Linux or FreeBSD, can you please > explain things? > > If everything is there except the support in the driver then I might be able > to add that to > my queue. > If we knew what the driver would need then that might help too :-) (ha gotcha) :-) > Cheers, > > Jack > > > On Thu, Oct 8, 2009 at 9:14 PM, Siquijor Philips > wrote: > >> On Fri, Oct 9, 2009 at 1:45 AM, Pyun YongHyeon wrote: >>> On Thu, Oct 08, 2009 at 01:24:20PM +0800, Siquijor Philips wrote: >>>> Hi, >>>> >>>> I got a dual-port Intel Gigabit NIC with 82576 (ET) chipset >>>> http://www.intel.com/Assets/PDF/prodbrief/320116.pdf. It has a feature >>>> on IPsec offloading but it only mentioned Microsoft Windows 2008 and >>>> Vista servers. I wonder if FreeBSD have also support on this feature? >>>> >>> AFAIK it's not yet, not sure whether Jack has plan to implement the >>> offloading. I know old Intel i82550 also supported IPSec offloading >>> but Intel didn't release required information to implement it. 3Com >>> also supported IPSec offloading in their 3XP hardwares(txp(4)) but >>> the offloading was not implemented. >>> >> Hi Pyun, >> >> Thanks for your info! By the way, who is Jack? Is he the author of >> this driver? I really need to have this feature usable on the driver. >> I bought these NICs with 82576 chipset for the purpose of implementing >> IPsec in my network and my current FreeBSD servers could benefit it. >> Just really thought it has support because FreeBSD was already part of >> the supported operating system. I was alerted when I've re-read the >> product info document again that it only support Windows 2008 and >> Vista platforms. Now, I've confirmed that with the current existing >> driver. I hope this guy has the plan of implementing it sooner because >> I really need it. >> >> Thanks, >> Siquijor >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From pyunyh at gmail.com Fri Oct 9 18:49:47 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Oct 9 18:49:54 2009 Subject: intel 82576 ipsec offload? In-Reply-To: <2a41acea0910091117q6cfab252sa8d5dfcf0182b660@mail.gmail.com> References: <20091008174521.GE3843@michelle.cdnetworks.com> <2a41acea0910091117q6cfab252sa8d5dfcf0182b660@mail.gmail.com> Message-ID: <20091009184831.GH3843@michelle.cdnetworks.com> On Fri, Oct 09, 2009 at 11:17:00AM -0700, Jack Vogel wrote: > I am Jack, the network engineer at Intel responsible for all FreeBSD wired > lan drivers. > This is the first I've seen about this. Our understanding was that the > infrastructure needed > to do IPSec was not available for either Linux or FreeBSD, can you please > explain things? > I guess we already have crypto(9) infrastructure to support IPSec in kernel. CCed to sam who may know what is required to implement IPSec offloading in ethernet driver. > If everything is there except the support in the driver then I might be able > to add that to > my queue. > > Cheers, > > Jack > > > On Thu, Oct 8, 2009 at 9:14 PM, Siquijor Philips > wrote: > > > On Fri, Oct 9, 2009 at 1:45 AM, Pyun YongHyeon wrote: > > > On Thu, Oct 08, 2009 at 01:24:20PM +0800, Siquijor Philips wrote: > > >> Hi, > > >> > > >> I got a dual-port Intel Gigabit NIC with 82576 (ET) chipset > > >> http://www.intel.com/Assets/PDF/prodbrief/320116.pdf. It has a feature > > >> on IPsec offloading but it only mentioned Microsoft Windows 2008 and > > >> Vista servers. I wonder if FreeBSD have also support on this feature? > > >> > > > > > > AFAIK it's not yet, not sure whether Jack has plan to implement the > > > offloading. I know old Intel i82550 also supported IPSec offloading > > > but Intel didn't release required information to implement it. 3Com > > > also supported IPSec offloading in their 3XP hardwares(txp(4)) but > > > the offloading was not implemented. > > > > > > > Hi Pyun, > > > > Thanks for your info! By the way, who is Jack? Is he the author of > > this driver? I really need to have this feature usable on the driver. > > I bought these NICs with 82576 chipset for the purpose of implementing > > IPsec in my network and my current FreeBSD servers could benefit it. > > Just really thought it has support because FreeBSD was already part of > > the supported operating system. I was alerted when I've re-read the > > product info document again that it only support Windows 2008 and > > Vista platforms. Now, I've confirmed that with the current existing > > driver. I hope this guy has the plan of implementing it sooner because > > I really need it. > > > > Thanks, > > Siquijor From julian at elischer.org Fri Oct 9 19:03:33 2009 From: julian at elischer.org (Julian Elischer) Date: Fri Oct 9 19:03:40 2009 Subject: intel 82576 ipsec offload? In-Reply-To: <20091009184831.GH3843@michelle.cdnetworks.com> References: <20091008174521.GE3843@michelle.cdnetworks.com> <2a41acea0910091117q6cfab252sa8d5dfcf0182b660@mail.gmail.com> <20091009184831.GH3843@michelle.cdnetworks.com> Message-ID: <4ACF8907.9000905@elischer.org> Pyun YongHyeon wrote: > On Fri, Oct 09, 2009 at 11:17:00AM -0700, Jack Vogel wrote: >> I am Jack, the network engineer at Intel responsible for all FreeBSD wired >> lan drivers. >> This is the first I've seen about this. Our understanding was that the >> infrastructure needed >> to do IPSec was not available for either Linux or FreeBSD, can you please >> explain things? >> > > I guess we already have crypto(9) infrastructure to support IPSec > in kernel. CCed to sam who may know what is required to implement > IPSec offloading in ethernet driver. > I guess what is required is dependent on whether it's just crypto support, or whether the card is expected to track all the security associations, or whether it expects to track just a subset of them. I'm guessing that the latter may be the case. From jfvogel at gmail.com Fri Oct 9 19:13:36 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Fri Oct 9 19:13:48 2009 Subject: intel 82576 ipsec offload? In-Reply-To: <4ACF8907.9000905@elischer.org> References: <20091008174521.GE3843@michelle.cdnetworks.com> <2a41acea0910091117q6cfab252sa8d5dfcf0182b660@mail.gmail.com> <20091009184831.GH3843@michelle.cdnetworks.com> <4ACF8907.9000905@elischer.org> Message-ID: <2a41acea0910091213p3d8ccbbq7c29b407ec0b4c79@mail.gmail.com> I am out sick today, but I will see what I can find out early next week. Jack On Fri, Oct 9, 2009 at 12:03 PM, Julian Elischer wrote: > Pyun YongHyeon wrote: > >> On Fri, Oct 09, 2009 at 11:17:00AM -0700, Jack Vogel wrote: >> >>> I am Jack, the network engineer at Intel responsible for all FreeBSD >>> wired >>> lan drivers. >>> This is the first I've seen about this. Our understanding was that the >>> infrastructure needed >>> to do IPSec was not available for either Linux or FreeBSD, can you please >>> explain things? >>> >>> >> I guess we already have crypto(9) infrastructure to support IPSec >> in kernel. CCed to sam who may know what is required to implement >> IPSec offloading in ethernet driver. >> >> > I guess what is required is dependent on whether it's just crypto > support, or whether the card is expected to track all the security > associations, or whether it expects to track just a subset of them. > > I'm guessing that the latter may be the case. > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From jacques.fourie at gmail.com Fri Oct 9 19:37:26 2009 From: jacques.fourie at gmail.com (Jacques Fourie) Date: Fri Oct 9 19:37:32 2009 Subject: Route re-calculation in ip_output() In-Reply-To: <4ACF5DA5.6060806@elischer.org> References: <4ACF5DA5.6060806@elischer.org> Message-ID: On Fri, Oct 9, 2009 at 5:58 PM, Julian Elischer wrote: > Jacques Fourie wrote: >> >> Hi, >> >> I've noticed what I believe to be a bug in ip_output(). The piece of >> code in question is when the firewall changes the destination address >> of an outgoing packet and the subsequent re-calculation of the route. >> The issue should be clear from the attached diff - basically what >> happens is that for the second route lookup dst can point to >> ro->ro_rt->rt_gateway instead of &ro->ro_dst. It seems as if this >> issue is present on 7,8 and 9? > > Is this a problem? > generally, the aim of a fwd firewall rule is to set the next hop > (gateway). so this may be what is required.. > > >> >> --- ip_output.c 2009-10-09 10:37:40.537408240 +0200 >> +++ /home/jacques/ip_output.c ? 2009-10-09 10:43:46.232819440 +0200 >> @@ -521,8 +521,10 @@ >> ?#endif >> ? ? ? ? ? ? ? ? ? ? ? ?error = netisr_queue(NETISR_IP, m); >> ? ? ? ? ? ? ? ? ? ? ? ?goto done; >> - ? ? ? ? ? ? ? } else >> + ? ? ? ? ? ? ? } else { >> + ? ? ? ? ? ? ? ? ? ? ? dst = (struct sockaddr_in *)&ro->ro_dst; >> ? ? ? ? ? ? ? ? ? ? ? ?goto again; ? ? /* Redo the routing table lookup. >> */ >> + ? ? ? ? ? ? ? } >> >> >> Regards, >> Jacques >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > If I understand everything correctly the handling of fwd rules seem to do exactly what I propose in the patch. See the code starting with 'if (fwd_tag) {' in ip_output.c? As far as I understand it fwd rules do not change the destination IP address in the mbuf so the patch will not affect the handling of fwd rules. Jacques From glen.j.barber at gmail.com Fri Oct 9 20:33:25 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Fri Oct 9 20:33:32 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <200910092003.57367.bschmidt@techwires.net> References: <20091009170839.142800@gmx.net> <200910092003.57367.bschmidt@techwires.net> Message-ID: <4ad871310910091333u29b5520aycf13971e163cbe5d@mail.gmail.com> Hi On Fri, Oct 9, 2009 at 6:03 PM, Bernhard Schmidt wrote: > On Friday 09 October 2009 19:08:39 Lutz Bichler wrote: >> Hi, >> >> does anybody know what happened to the attempts to support Intel WiFi >> ?5100/5300 interfaces in the iwn-driver? Are any patches available which >> ?could be used to start working on support for these interfaces? > > I'm curious too, as I'm playing with idea to start porting the latest changes > to if_iwn from OpenBSD. Already started with adding the 5000 series firmware to > iwnfw... > If you need patches tested for 8-STABLE for the 5100 AGN, I am more than happy to test. -- Glen Barber From ml at netfence.it Fri Oct 9 21:36:12 2009 From: ml at netfence.it (Andrea Venturoli) Date: Fri Oct 9 21:36:18 2009 Subject: FreeBSD + Samba + Active Directory Message-ID: <4ACFACC9.5010605@netfence.it> Hello. I have a setup with two FreeBSD 6.3 domain controllers using samba + openldap + nss_ldap. The company might be switching to Active Directory soon (not my choice, before you ask :-), so I might need to reconfigure the two FreeBSD boxes to become AD members (with winbindd, nss, whatever). I see there's a lot of documentation around and I'm going to read that; here I just want to ask if everything works as advertised, if there are some differences between theory and practice, bugs to watch for, gotchas, etc... Thanks in advance to anyone who cares to share it's experience. bye & Thanks av. From tom at tomjudge.com Fri Oct 9 21:54:45 2009 From: tom at tomjudge.com (Tom Judge) Date: Fri Oct 9 21:54:51 2009 Subject: FreeBSD + Samba + Active Directory In-Reply-To: <4ACFACC9.5010605@netfence.it> References: <4ACFACC9.5010605@netfence.it> Message-ID: <4ACFB0FB.8070501@tomjudge.com> Andrea Venturoli wrote: > Hello. > > I have a setup with two FreeBSD 6.3 domain controllers using samba + > openldap + nss_ldap. > The company might be switching to Active Directory soon (not my > choice, before you ask :-), so I might need to reconfigure the two > FreeBSD boxes to become AD members (with winbindd, nss, whatever). > > I see there's a lot of documentation around and I'm going to read > that; here I just want to ask if everything works as advertised, if > there are some differences between theory and practice, bugs to watch > for, gotchas, etc... > > Thanks in advance to anyone who cares to share it's experience. Here is our recipe: 1) Install security/krb5 2) Install net/samba3 with ADS support and set KRB5_HOME=/usr/local 3) Setup /etc/krb5.conf and smb.conf 4) Link /usr/local/etc/krb5.conf to /etc/krb5.conf 5) kinit administrator 6) net ads join 7) net ads testjoin Hope this helps Tom From nikolai.saoukh at gmail.com Sat Oct 10 09:50:02 2009 From: nikolai.saoukh at gmail.com (Nikolai Saoukh) Date: Sat Oct 10 09:50:09 2009 Subject: kern/139204: [arp] DHCP server replies rejected, ARP entry lost before max_age Message-ID: <200910100950.n9A9o2wM088285@freefall.freebsd.org> The following reply was made to PR kern/139204; it has been noted by GNATS. From: Nikolai Saoukh To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/139204: [arp] DHCP server replies rejected, ARP entry lost before max_age Date: Sat, 10 Oct 2009 13:25:46 +0400 > I'm going to make a guess that this is ARP-related, based on a comment > in the PR. After some inspection I think the problem is in /sbin/dhclient. Patch in PR bin/96018 introduced unicast REQUESTs. That requests are sent from random port (not from bootpc (68)), thus defeating bpf filter in dhclient for replies. Moreover when there are two or more interfaces on the same network, that requests can be transmitted from another interface (with different ethernet address). IP packet with the same IP number (but changed ethernet address) confuse ARP machinery. See also PR ports/139405. IMHO, category, severity, ... of this PR should be edited. From siquijorphilips at gmail.com Sat Oct 10 15:03:16 2009 From: siquijorphilips at gmail.com (Siquijor Philips) Date: Sat Oct 10 15:03:29 2009 Subject: intel 82576 ipsec offload? In-Reply-To: <2a41acea0910091117q6cfab252sa8d5dfcf0182b660@mail.gmail.com> References: <20091008174521.GE3843@michelle.cdnetworks.com> <2a41acea0910091117q6cfab252sa8d5dfcf0182b660@mail.gmail.com> Message-ID: On Sat, Oct 10, 2009 at 2:17 AM, Jack Vogel wrote: > I am Jack, the network engineer at Intel responsible for all FreeBSD wired > lan drivers. Hi Jack! Thanks for introducing yourself since I am new to this mailing list :-) > This is the first I've seen about this. Our understanding was that the > infrastructure needed > to do IPSec was not available for either Linux or FreeBSD, can you please > explain things? > Yes, basically I am implementing an IPsec infrastructure to our network. Our network is composed of a main office and 3 branch offices to be linked over VPN. I'm using both FreeBSD and Windows platforms. Our FreeBSD (7.1-Release) platforms comprises the 4 firewall/gateways (which should be also our VPN concentrators) as well as our mail server (7.1-Release). The Windows platforms comprises the local/remote clients (FreeBSD/Windows XP/Vista) and the Active Directory server (Windows Server 2008). Since our 4 FreeBSD perimeter firewall/gateways are currently processing big amount of traffic, so I have decided to buy these Intel NICs with IPsec offloading just to make sure it can carry out the current traffic processing. Aside from that, our local and remote FreeBSD clients will also be configured on transport-mode IPsec sooner because these clients are also network intensive hosts. So, from here I really wanted to have the IPsec offloading be available to my NICs since I intend to buy these as its primary purpose. > If everything is there except the support in the driver then I might be able > to add that to > my queue. > Yes, please because I really need to have my IPsec infra working sooner. Thank you so much! Siquijor > Cheers, > > Jack > > > On Thu, Oct 8, 2009 at 9:14 PM, Siquijor Philips > wrote: >> >> On Fri, Oct 9, 2009 at 1:45 AM, Pyun YongHyeon wrote: >> > On Thu, Oct 08, 2009 at 01:24:20PM +0800, Siquijor Philips wrote: >> >> Hi, >> >> >> >> I got a dual-port Intel Gigabit NIC with 82576 (ET) chipset >> >> http://www.intel.com/Assets/PDF/prodbrief/320116.pdf. It has a feature >> >> on IPsec offloading but it only mentioned Microsoft Windows 2008 and >> >> Vista servers. I wonder if FreeBSD have also support on this feature? >> >> >> > >> > AFAIK it's not yet, not sure whether Jack has plan to implement the >> > offloading. I know old Intel i82550 also supported IPSec offloading >> > but Intel didn't release required information to implement it. 3Com >> > also supported IPSec offloading in their 3XP hardwares(txp(4)) but >> > the offloading was not implemented. >> > >> >> Hi Pyun, >> >> Thanks for your info! By the way, who is Jack? Is he the author of >> this driver? I really need to have this feature usable on the driver. >> I bought these NICs with 82576 chipset for the purpose of implementing >> IPsec in my network and my current FreeBSD servers could benefit it. >> Just really thought it has support because FreeBSD was already part of >> the supported operating system. I was alerted when I've re-read the >> product info document again that it only support Windows 2008 and >> Vista platforms. Now, I've confirmed that with the current existing >> driver. I hope this guy has the plan of implementing it sooner because >> I really need it. >> >> Thanks, >> Siquijor >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From to.my.trociny at gmail.com Sun Oct 11 18:05:16 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Sun Oct 11 18:05:22 2009 Subject: host(1) coredumps In-Reply-To: <20090913171643.GA69039@svzserv.kemerovo.su> (Eugene Grosbein's message of "Mon\, 14 Sep 2009 01\:16\:43 +0800") References: <20090913042742.GA32897@svzserv.kemerovo.su> <4AAD12BE.1090600@vwsoft.com> <20090913171643.GA69039@svzserv.kemerovo.su> Message-ID: <86ocodzv3j.fsf@kopusha.onet> On Mon, 14 Sep 2009 01:16:43 +0800 Eugene Grosbein wrote: EG> On Sun, Sep 13, 2009 at 05:41:50PM +0200, volker@vwsoft.com wrote: >> > % host -l grosbein.pp.ru. ns2.rucable.net. >> > ; Transfer failed. >> > /usr/local/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:2486: >> > REQUIRE((((sock) != ((void *)0)) && (((const isc__magic_t *)(sock))->magic >> > == ((('I') << 24 | ('O') << 16 | ('i') << 8 | ('o')))))) failed. >> > zsh: abort (core dumped) host -l grosbein.pp.ru. ns2.rucable.net. >> > >> > Shoud I send PR? >> Eugene, >> >> the attached patch works around the error for me. As this is contributed >> code, it should be fixed upstream (no need to file a PR). >> >> Volker >> >> --- contrib/bind9/bin/dig/dighost.c.orig 2009-09-13 14:24:13.000000000 +0000 >> +++ contrib/bind9/bin/dig/dighost.c 2009-09-13 14:31:52.000000000 +0000 EG> Indeed, the patch helps. Thank you. BTW, we have already had the pr about this problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/138061 IMO it would be nice to add the patch there. -- Mikolaj Golub From dougb at FreeBSD.org Sun Oct 11 19:31:35 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sun Oct 11 19:31:41 2009 Subject: host(1) coredumps In-Reply-To: <86ocodzv3j.fsf@kopusha.onet> References: <20090913042742.GA32897@svzserv.kemerovo.su> <4AAD12BE.1090600@vwsoft.com> <20090913171643.GA69039@svzserv.kemerovo.su> <86ocodzv3j.fsf@kopusha.onet> Message-ID: <4AD22C54.6070107@FreeBSD.org> Mikolaj Golub wrote: > BTW, we have already had the pr about this problem. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/138061 > > IMO it would be nice to add the patch there. Normally that would be a good idea, but I've just adopted the PR and sent a link to it and the patch to the bind-users list. Assuming we get a thumbs up I'll take care of adding it to the port and the base. Thanks, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From inpcb.harsha at gmail.com Sun Oct 11 19:40:20 2009 From: inpcb.harsha at gmail.com (Harsha Srinath) Date: Sun Oct 11 19:40:32 2009 Subject: Page fault in IFNET_WLOCK_ASSERT [if.c and pccbb.c] Message-ID: Hi all, I'm running an updated HEAD kernel and got a page fault in ifindex_alloc_locked() in if.c. I figured that the problem was caused by the (pluggable) network card of my laptop and found that during the initialization of the interface, cb_event_thread() takes the giant lock and up the call chain in if_alloc(), we call IFNET_WLOCK() and assert on the RW locks in ifindex_alloc_locked(). It is in the asset macro IFNET_WLOCK_ASSERT() I see the page fault. I looked up some recent related changes and noticed the following comment in one of the check-ins in- http://svn.freebsd.org/viewvc/base/head/sys/net/if.c "Break out allocation of new ifindex values from if_alloc() and if_vmove(), and centralize in a single function ifindex_alloc(). Assert the IFNET_WLOCK, and add missing IFNET_WLOCK in if_alloc(). This does not close all known races in this code." So I think I have hit one of those fault conditions. Apparently the giant lock code was removed and added back recently - http://svn.freebsd.org/viewvc/base/head/sys/dev/pccbb/pccbb.c I believe that the root cause is that ifnet_rw is a non sleepable exclusive RW lock and we have taken the exclusive sleep mutex Giant before that. Any pointers and suggestions are welcome. Many thanks, Harsha From rwatson at FreeBSD.org Sun Oct 11 20:30:58 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Oct 11 20:31:31 2009 Subject: Page fault in IFNET_WLOCK_ASSERT [if.c and pccbb.c] In-Reply-To: References: Message-ID: On Sun, 11 Oct 2009, Harsha Srinath wrote: > I'm running an updated HEAD kernel and got a page fault in > ifindex_alloc_locked() in if.c. I figured that the problem was caused by the > (pluggable) network card of my laptop and found that during the > initialization of the interface, cb_event_thread() takes the giant lock and > up the call chain in if_alloc(), we call IFNET_WLOCK() and assert on the RW > locks in ifindex_alloc_locked(). It is in the asset macro > IFNET_WLOCK_ASSERT() I see the page fault. > > I looked up some recent related changes and noticed the following comment in > one of the check-ins in- > http://svn.freebsd.org/viewvc/base/head/sys/net/if.c > > "Break out allocation of new ifindex values from if_alloc() and if_vmove(), > and centralize in a single function ifindex_alloc(). Assert the IFNET_WLOCK, > and add missing IFNET_WLOCK in if_alloc(). This does not close all known > races in this code." > > So I think I have hit one of those fault conditions. > > Apparently the giant lock code was removed and added back recently - > http://svn.freebsd.org/viewvc/base/head/sys/dev/pccbb/pccbb.c > > I believe that the root cause is that ifnet_rw is a non sleepable exclusive > RW lock and we have taken the exclusive sleep mutex Giant before that. > > Any pointers and suggestions are welcome. Hi Harsha-- Giant is a bit special in that the long-term sleep code in the kernel knows to drop it when sleeping, and re-acquire when waking up. So, unlike all other mutexes, it should be OK to hold it in this case, as Giant will simply get dropped if the kernel has to sleep waiting on a sleepable lock. This is because, historically in FreeBSD 3.x/4.x, the kernel was protected by a single spinlock, which would get released whenever the kernel stopped executing, such as during an I/O sleep. On the whole, Giant has disappeared from the modern kernel, but where it is used, it retains those curious historic properties. To break things down a bit further, IFNET_WLOCK is, itself, a bit special: notice that in FreeBSD 8, it's actually two locks, a sleep lock, and a mutex, which must both be acquired exclusively to ensure mutual exclusion. if_alloc() and associated calls are also sleepable because they perform potentially sleeping memory allocation (M_WAITOK), so it's an invariant of any code calling interface allocation that it must be able to tolerate a sleep. Do you have a copy of the stack trace and fault information handy? In my experience, a NULL pointer deref or other page fault in the locking code for a global lock is almost always corrupted thread state, perhaps due to tripping over another thread having locked a corrupted/freed/uninitialized lock. We might be able to track that down by tracing other threads that were in execution at the time of the panic. Robert From inpcb.harsha at gmail.com Mon Oct 12 04:38:34 2009 From: inpcb.harsha at gmail.com (Harsha) Date: Mon Oct 12 04:38:41 2009 Subject: Page fault in IFNET_WLOCK_ASSERT [if.c and pccbb.c] In-Reply-To: References: Message-ID: Hi Robert, On Sun, Oct 11, 2009 at 1:30 PM, Robert Watson wrote: > Giant is a bit special in that the long-term sleep code in the kernel knows > to drop it when sleeping, and re-acquire when waking up. ?So, unlike all > other mutexes, it should be OK to hold it in this case, as Giant will simply > get dropped if the kernel has to sleep waiting on a sleepable lock. ?This is > because, historically in FreeBSD 3.x/4.x, the kernel was protected by a > single spinlock, which would get released whenever the kernel stopped > executing, such as during an I/O sleep. ?On the whole, Giant has disappeared > from the modern kernel, but where it is used, it retains those curious > historic properties. > > To break things down a bit further, IFNET_WLOCK is, itself, a bit special: > notice that in FreeBSD 8, it's actually two locks, a sleep lock, and a > mutex, which must both be acquired exclusively to ensure mutual exclusion. > if_alloc() and associated calls are also sleepable because they perform > potentially sleeping memory allocation (M_WAITOK), so it's an invariant of > any code calling interface allocation that it must be able to tolerate a > sleep. Thanks a lot for the clarification. I had assumed that the lock was non-sleepable looking at this log - Kernel page fault with the following non-sleepable locks held: exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xc0f63464) locked @ /usr/src/sys/net/if.c:409 > Do you have a copy of the stack trace and fault information handy? ?In my > experience, a NULL pointer deref or other page fault in the locking code for > a global lock is almost always corrupted thread state, perhaps due to > tripping over another thread having locked a corrupted/freed/uninitialized > lock. ?We might be able to track that down by tracing other threads that > were in execution at the time of the panic. I just tried the textdump feature and I think its an awesome tool. Here is ddb.txt- http://docs.google.com/View?id=dddwnxfj_0dh4x58hc And msgbuf.txt- http://docs.google.com/View?id=dddwnxfj_1cnmrb8fw For some reason the output of show alllocks is not written into ddb.txt, though I have increased the buffer size to 2MB. Thanks, Harsha From aman.jassal at esigetel.fr Mon Oct 12 09:26:43 2009 From: aman.jassal at esigetel.fr (JASSAL Aman) Date: Mon Oct 12 09:26:49 2009 Subject: Volunteer opportunity for Networking tasks In-Reply-To: <4ACF5DA5.6060806@elischer.org> References: <4ACF5DA5.6060806@elischer.org> Message-ID: <8410.83.206.131.26.1255338115.squirrel@webmail.esigetel.fr> Dear all, I am interested in contributing to the networking tasks of the FreeBSD project. Having been on the freebsd-net mailing-list for about 6 months now (and freebsd-current more recently), I really want to make myself useful, and provide help in completing tasks on networking or wireless networking areas. I had been on the Networking Wikipage (this one : http://wiki.freebsd.org/Networking), which describes the current on-going tasks, I had been working over the last 2 weeks on rewriting some parts of netstat(1) (mainly the part dumping the routing table) to make it use sysctl rather than kvm. However after reading Mr.Gerzo's mail about the FreeBSD Status Reports from yesterday evening, which talked about libnetstat(), I'm starting to wonder whether whatever work I've done so far is actually worthwhile... I was thinking of getting some experience on board before volunteering for further work. There are a good few tasks mentionned on the Networking Wikipage that interest me a lot, so I'll just start working on something else if that work is no longer required for netstat :-). Please make me aware of any opportunities or tasks in which there is a need for more people, I'd be greatly honoured to provide help. -------------- Aman Jassal From bugmaster at FreeBSD.org Mon Oct 12 11:06:58 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 12 11:08:52 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200910121106.n9CB6v6V036484@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139162 net [fwip] [panic] 8.0-RC1 panics if using IP over firewir o kern/139145 net [ip6] IPv6 blackhole / reject routes broken o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139113 net [arp] removing IP alias doesn't delete permanent arp e o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138999 net [libc] lighttpd/php-cgi with freebsd sendfile(2) enabl o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o kern/138694 net [bge] FreeBSD 6.3 release does not recognize Broadcom o amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138676 net [route] after buildworld not work local routes [regres f kern/138666 net [multicast] [panic] not working multicast through igmp o kern/138660 net [igb] igb driver troubles in 8.0-BETA4 o kern/138652 net TCP window scaling value calculated incorrectly? o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138390 net [gif] [patch] NULL pointer dereference in gif_input() o kern/138378 net [altq] [patch] Memory leak in hfsc_class_modify() in f o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR on 8.0-BE o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/138130 net [netinet] [patch] Resource leak in LibAliasRefreshModu o kern/138046 net [tcp] tcp sockets stay in SYN_SENT even after receivin o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137795 net [sctp] [panic] mtx_lock() of destroyed mutex o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137317 net [tcp] logs full of syncache problems o kern/137292 net [ste] DFE-580TX not working properly o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136482 net [age] Attansic L1 Gigabit Ethernet recieves multicasts o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135836 net [bce] bce BCM5709 Watchdog after warm boot - ok after o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/135067 net [patch] [fib] Incorrect KASSERTs in sys/net/route.c o kern/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se o kern/134931 net [route] [fib] Route messages sent to all socket listen o kern/134658 net [bce] bce driver fails on PowerEdge m610 blade. o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134369 net [route] [ip6] IPV6 in Head broken for routing table up o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133786 net [netinet] [patch] ip_input might cause kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132625 net [iwn] iwn drivers don't support setting country o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] [patch] if_sis short cable fix problems with Net s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 357 problems total. From rwatson at freebsd.org Mon Oct 12 13:46:06 2009 From: rwatson at freebsd.org (Robert N. M. Watson) Date: Mon Oct 12 13:46:18 2009 Subject: Page fault in IFNET_WLOCK_ASSERT [if.c and pccbb.c] In-Reply-To: References: Message-ID: On 12 Oct 2009, at 05:38, Harsha wrote: > Thanks a lot for the clarification. > > I had assumed that the lock was non-sleepable looking at this log - > Kernel page fault with the following non-sleepable locks held: > exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xc0f63464) locked @ > /usr/src/sys/net/if.c:409 Looks like a NULL pointer dereference, so perhaps a more traditional bug -- could you convert ifindex_alloc_locked+0x71 to a line of code? You can do this using kgdb on the kernel symbols file, perhaps "l *ifindex_alloc_locked+0x71". Robert From lab at gta.com Mon Oct 12 14:41:53 2009 From: lab at gta.com (Larry Baird) Date: Mon Oct 12 14:42:00 2009 Subject: ARP changes Message-ID: <20091012144149.GA39393@gta.com> I know that arp has changed a lot in FreeBSD 8. I am wondering if one change was by design? In older versions of FreeBSD, if you ping a host that is on a local network but is down, after a few seconds ping displays: ping: sendto: Host is down ping: sendto: Host is down Using arp to display the arp table shows: host.domain (x.x.x.x) at (incomplete) on em0 [ethernet] In FreeBSD 8, the incomplete arp entries don't show up. Ping never prints "Host is down'. The old behaviors can useful when trouble shooting local network problems. Is there a reason for the changes? -- ------------------------------------------------------------------------ Larry Baird | http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 From qing.li at bluecoat.com Mon Oct 12 17:05:15 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Mon Oct 12 17:05:23 2009 Subject: ARP changes In-Reply-To: <20091012144149.GA39393@gta.com> References: <20091012144149.GA39393@gta.com> Message-ID: Might be a regression issue. I will take a look and get back to you later today. -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Larry Baird > Sent: Monday, October 12, 2009 7:42 AM > To: freebsd-net@freebsd.org > Subject: ARP changes > > I know that arp has changed a lot in FreeBSD 8. I am wondering if one > change was by design? In older versions of FreeBSD, if you ping a host > that is on a local network but is down, after a few seconds ping > displays: > ping: sendto: Host is down > ping: sendto: Host is down > > Using arp to display the arp table shows: > host.domain (x.x.x.x) at (incomplete) on em0 [ethernet] > > In FreeBSD 8, the incomplete arp entries don't show up. Ping never > prints "Host is down'. The old behaviors can useful when trouble > shooting local network problems. Is there a reason for the changes? > > > -- > ----------------------------------------------------------------------- > - > Larry Baird | http://www.gta.com > Global Technology Associates, Inc. | Orlando, FL > Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From mike at sentex.net Mon Oct 12 17:41:22 2009 From: mike at sentex.net (Mike Tancsa) Date: Mon Oct 12 17:41:30 2009 Subject: ARP changes In-Reply-To: References: <20091012144149.GA39393@gta.com> Message-ID: <200910121741.n9CHfI9Q081109@lava.sentex.ca> At 01:05 PM 10/12/2009, Li, Qing wrote: >Might be a regression issue. I will take a look and get back >to you later today. Actually, the behaviour is different on RELENG_6, RELENG_7 and RELENG_8. On RELENG_6, the negative entry is cached for some, on RELENG_7, less than 1 second and on RELENG_8, it never shows up at all ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From bz at FreeBSD.org Mon Oct 12 21:56:47 2009 From: bz at FreeBSD.org (bz@FreeBSD.org) Date: Mon Oct 12 21:56:54 2009 Subject: kern/116328: [bge]: Solid hang with bge interface Message-ID: <200910122156.n9CLukCD016220@freefall.freebsd.org> Synopsis: [bge]: Solid hang with bge interface Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Mon Oct 12 21:56:26 UTC 2009 Responsible-Changed-Why: Take for the moment. http://www.freebsd.org/cgi/query-pr.cgi?pr=116328 From bz at FreeBSD.org Mon Oct 12 21:57:14 2009 From: bz at FreeBSD.org (bz@FreeBSD.org) Date: Mon Oct 12 21:57:24 2009 Subject: kern/122252: [ipmi] [bge] IPMI problem with BCM5704 (does not work after driver loaded) Message-ID: <200910122157.n9CLvEmX016299@freefall.freebsd.org> Synopsis: [ipmi] [bge] IPMI problem with BCM5704 (does not work after driver loaded) Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Mon Oct 12 21:57:02 UTC 2009 Responsible-Changed-Why: Take for the moment. http://www.freebsd.org/cgi/query-pr.cgi?pr=122252 From dougb at FreeBSD.org Mon Oct 12 22:21:07 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Oct 12 22:21:19 2009 Subject: Wacky DHCP values that work in windows but not in FreeBSD Message-ID: <4AD3ABD0.7010603@FreeBSD.org> Howdy, I usually have a wireless router connected directly to the AT&T/Yahoo DSL modem but last night I wanted to do some debugging so I plugged my laptop directly into the modem (after powering off the modem, etc.). The values I got back from DHCP not only don't make sense, they didn't work in FreeBSD at all. Dual-booting to Windows showed that the values I saw from DHCP were "correct," and somehow they managed to work. Taking a closer look at the router after I plugged it back in showed the same. Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 76.212.147.xxx Subnet Mask . . . . . . . . . . . : 255.255.0.0 Default Gateway . . . . . . . . . : 151.164.184.xxx DHCP Server . . . . . . . . . . . : 192.168.1.xxx DNS Servers . . . . . . . . . . . : 192.168.1.xxx Can anyone tell me how they managed to get this to work in Windows, and suggest where to look to get it working in FreeBSD? Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From julian at elischer.org Mon Oct 12 22:59:45 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Oct 12 22:59:53 2009 Subject: Wacky DHCP values that work in windows but not in FreeBSD In-Reply-To: <4AD3ABD0.7010603@FreeBSD.org> References: <4AD3ABD0.7010603@FreeBSD.org> Message-ID: <4AD3B4E3.2090406@elischer.org> Doug Barton wrote: > Howdy, > > I usually have a wireless router connected directly to the AT&T/Yahoo > DSL modem but last night I wanted to do some debugging so I plugged my > laptop directly into the modem (after powering off the modem, etc.). > > The values I got back from DHCP not only don't make sense, they didn't > work in FreeBSD at all. Dual-booting to Windows showed that the values > I saw from DHCP were "correct," and somehow they managed to work. > Taking a closer look at the router after I plugged it back in showed > the same. > > Dhcp Enabled. . . . . . . . . . . : Yes > Autoconfiguration Enabled . . . . : Yes > IP Address. . . . . . . . . . . . : 76.212.147.xxx > Subnet Mask . . . . . . . . . . . : 255.255.0.0 > Default Gateway . . . . . . . . . : 151.164.184.xxx huh? only way this could work would be if it was marked as "point to point" I think.. > DHCP Server . . . . . . . . . . . : 192.168.1.xxx > DNS Servers . . . . . . . . . . . : 192.168.1.xxx > > Can anyone tell me how they managed to get this to work in Windows, > and suggest where to look to get it working in FreeBSD? > > > Doug > From mksmith at adhost.com Mon Oct 12 23:14:09 2009 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Mon Oct 12 23:14:15 2009 Subject: Wacky DHCP values that work in windows but not in FreeBSD In-Reply-To: <4AD3B4E3.2090406@elischer.org> References: <4AD3ABD0.7010603@FreeBSD.org> <4AD3B4E3.2090406@elischer.org> Message-ID: <17838240D9A5544AAA5FF95F8D52031606D020C7@ad-exh01.adhost.lan> > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Julian Elischer > Sent: Monday, October 12, 2009 4:00 PM > To: Doug Barton > Cc: freebsd-net@freebsd.org > Subject: Re: Wacky DHCP values that work in windows but not in FreeBSD > > Doug Barton wrote: > > Howdy, > > > > I usually have a wireless router connected directly to the AT&T/Yahoo > > DSL modem but last night I wanted to do some debugging so I plugged > my > > laptop directly into the modem (after powering off the modem, etc.). > > > > The values I got back from DHCP not only don't make sense, they > didn't > > work in FreeBSD at all. Dual-booting to Windows showed that the > values > > I saw from DHCP were "correct," and somehow they managed to work. > > Taking a closer look at the router after I plugged it back in showed > > the same. > > > > Dhcp Enabled. . . . . . . . . . . : Yes > > Autoconfiguration Enabled . . . . : Yes > > IP Address. . . . . . . . . . . . : 76.212.147.xxx > > Subnet Mask . . . . . . . . . . . : 255.255.0.0 > > Default Gateway . . . . . . . . . : 151.164.184.xxx > > huh? > > only way this could work would be if it was marked as "point to point" > I think.. That could be a primary IP address on an interface on which your 76 address is a sub interface. The interface will do proxy-arp when a traffic request comes in. Or something else! I'm not sure if this will work, but you could actually hard code your default gateway with a -hopcount 2 (or higher) and see if that works. I've not tried it on a live machine. Something like route add default 151.164.184.xxx -hopcount 5. You may have to delete the DHCP-assigned entry first. Regards, Mike From dougb at FreeBSD.org Mon Oct 12 23:21:33 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Oct 12 23:21:40 2009 Subject: Wacky DHCP values that work in windows but not in FreeBSD In-Reply-To: <17838240D9A5544AAA5FF95F8D52031606D020C7@ad-exh01.adhost.lan> References: <4AD3ABD0.7010603@FreeBSD.org> <4AD3B4E3.2090406@elischer.org> <17838240D9A5544AAA5FF95F8D52031606D020C7@ad-exh01.adhost.lan> Message-ID: <4AD3B9FB.4010205@FreeBSD.org> Michael K. Smith - Adhost wrote: >> -----Original Message----- >> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- >> net@freebsd.org] On Behalf Of Julian Elischer >> Sent: Monday, October 12, 2009 4:00 PM >> To: Doug Barton >> Cc: freebsd-net@freebsd.org >> Subject: Re: Wacky DHCP values that work in windows but not in FreeBSD >> >> Doug Barton wrote: >>> Howdy, >>> >>> I usually have a wireless router connected directly to the > AT&T/Yahoo >>> DSL modem but last night I wanted to do some debugging so I plugged >> my >>> laptop directly into the modem (after powering off the modem, etc.). >>> >>> The values I got back from DHCP not only don't make sense, they >> didn't >>> work in FreeBSD at all. Dual-booting to Windows showed that the >> values >>> I saw from DHCP were "correct," and somehow they managed to work. >>> Taking a closer look at the router after I plugged it back in showed >>> the same. >>> >>> Dhcp Enabled. . . . . . . . . . . : Yes >>> Autoconfiguration Enabled . . . . : Yes >>> IP Address. . . . . . . . . . . . : 76.212.147.xxx >>> Subnet Mask . . . . . . . . . . . : 255.255.0.0 >>> Default Gateway . . . . . . . . . : 151.164.184.xxx >> huh? >> >> only way this could work would be if it was marked as "point to point" >> I think.. > > That could be a primary IP address on an interface on which your 76 > address is a sub interface. Can you specify what you mean by 'that'? > The interface will do proxy-arp when a > traffic request comes in. Or something else! I'm not sure if this will > work, but you could actually hard code your default gateway with a > -hopcount 2 (or higher) and see if that works. I've not tried it on a > live machine. Something like route add default 151.164.184.xxx > -hopcount 5. You may have to delete the DHCP-assigned entry first. Ah, I didn't know about -hopcount, thanks. There was no default route installed at all when I booted. I tried 'route add default 151...' even though I was sure it wouldn't work, and I was not disappointed. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From julian at elischer.org Mon Oct 12 23:25:58 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Oct 12 23:26:04 2009 Subject: Wacky DHCP values that work in windows but not in FreeBSD In-Reply-To: <4AD3B9FB.4010205@FreeBSD.org> References: <4AD3ABD0.7010603@FreeBSD.org> <4AD3B4E3.2090406@elischer.org> <17838240D9A5544AAA5FF95F8D52031606D020C7@ad-exh01.adhost.lan> <4AD3B9FB.4010205@FreeBSD.org> Message-ID: <4AD3BB07.3070109@elischer.org> Doug Barton wrote: > Michael K. Smith - Adhost wrote: >>> -----Original Message----- >>> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- >>> net@freebsd.org] On Behalf Of Julian Elischer >>> Sent: Monday, October 12, 2009 4:00 PM >>> To: Doug Barton >>> Cc: freebsd-net@freebsd.org >>> Subject: Re: Wacky DHCP values that work in windows but not in FreeBSD >>> >>> Doug Barton wrote: >>>> Howdy, >>>> >>>> I usually have a wireless router connected directly to the >> AT&T/Yahoo >>>> DSL modem but last night I wanted to do some debugging so I plugged >>> my >>>> laptop directly into the modem (after powering off the modem, etc.). >>>> >>>> The values I got back from DHCP not only don't make sense, they >>> didn't >>>> work in FreeBSD at all. Dual-booting to Windows showed that the >>> values >>>> I saw from DHCP were "correct," and somehow they managed to work. >>>> Taking a closer look at the router after I plugged it back in showed >>>> the same. >>>> >>>> Dhcp Enabled. . . . . . . . . . . : Yes >>>> Autoconfiguration Enabled . . . . : Yes >>>> IP Address. . . . . . . . . . . . : 76.212.147.xxx >>>> Subnet Mask . . . . . . . . . . . : 255.255.0.0 >>>> Default Gateway . . . . . . . . . : 151.164.184.xxx >>> huh? >>> >>> only way this could work would be if it was marked as "point to point" >>> I think.. >> That could be a primary IP address on an interface on which your 76 >> address is a sub interface. > > Can you specify what you mean by 'that'? > >> The interface will do proxy-arp when a >> traffic request comes in. Or something else! I'm not sure if this will >> work, but you could actually hard code your default gateway with a >> -hopcount 2 (or higher) and see if that works. I've not tried it on a >> live machine. Something like route add default 151.164.184.xxx >> -hopcount 5. You may have to delete the DHCP-assigned entry first. > > Ah, I didn't know about -hopcount, thanks. There was no default route > installed at all when I booted. I tried 'route add default 151...' > even though I was sure it wouldn't work, and I was not disappointed. > > Doug > also not sure if you can add a -iface argument to make your default route include the correct interface . From security at jim-liesl.org Mon Oct 12 23:33:42 2009 From: security at jim-liesl.org (security) Date: Mon Oct 12 23:33:48 2009 Subject: Wacky DHCP values that work in windows but not in FreeBSD In-Reply-To: <4AD3B4E3.2090406@elischer.org> References: <4AD3ABD0.7010603@FreeBSD.org> <4AD3B4E3.2090406@elischer.org> Message-ID: <4AD3B67F.4070906@jim-liesl.org> Julian Elischer wrote: > Doug Barton wrote: >> Howdy, >> >> I usually have a wireless router connected directly to the AT&T/Yahoo >> DSL modem but last night I wanted to do some debugging so I plugged my >> laptop directly into the modem (after powering off the modem, etc.). >> >> The values I got back from DHCP not only don't make sense, they didn't >> work in FreeBSD at all. Dual-booting to Windows showed that the values >> I saw from DHCP were "correct," and somehow they managed to work. >> Taking a closer look at the router after I plugged it back in showed >> the same. >> >> Dhcp Enabled. . . . . . . . . . . : Yes >> Autoconfiguration Enabled . . . . : Yes >> IP Address. . . . . . . . . . . . : 76.212.147.xxx >> Subnet Mask . . . . . . . . . . . : 255.255.0.0 >> Default Gateway . . . . . . . . . : 151.164.184.xxx > > huh? > > only way this could work would be if it was marked as "point to point" > I think.. > >> DHCP Server . . . . . . . . . . . : 192.168.1.xxx >> DNS Servers . . . . . . . . . . . : 192.168.1.xxx >> >> Can anyone tell me how they managed to get this to work in Windows, >> and suggest where to look to get it working in FreeBSD? >> >> >> Doug >> ATT uses PPPoE on their modems. Did your router have any special PPPoE settings? jim From dougb at FreeBSD.org Mon Oct 12 23:52:39 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Oct 12 23:52:58 2009 Subject: Wacky DHCP values that work in windows but not in FreeBSD In-Reply-To: <4AD3B67F.4070906@jim-liesl.org> References: <4AD3ABD0.7010603@FreeBSD.org> <4AD3B4E3.2090406@elischer.org> <4AD3B67F.4070906@jim-liesl.org> Message-ID: <4AD3C145.5080501@FreeBSD.org> security wrote: > ATT uses PPPoE on their modems. Did your router have any special PPPoE > settings? It's a two-piece thing, "their" modem and my wireless router. The wireless router and windows know what to do with the info they are handed from the modem, FreeBSD doesn't. Sorry if I wasn't clear, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From dougb at FreeBSD.org Mon Oct 12 23:59:13 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Oct 12 23:59:20 2009 Subject: host(1) coredumps In-Reply-To: <4AAD12BE.1090600@vwsoft.com> References: <20090913042742.GA32897@svzserv.kemerovo.su> <4AAD12BE.1090600@vwsoft.com> Message-ID: <4AD3C2CC.8000607@FreeBSD.org> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20091012/546df154/signature.pgp From eugen at kuzbass.ru Tue Oct 13 00:07:08 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Tue Oct 13 00:07:14 2009 Subject: host(1) coredumps In-Reply-To: <4AD3C2CC.8000607@FreeBSD.org> References: <20090913042742.GA32897@svzserv.kemerovo.su> <4AAD12BE.1090600@vwsoft.com> <4AD3C2CC.8000607@FreeBSD.org> Message-ID: <20091013000704.GA59405@svzserv.kemerovo.su> On Mon, Oct 12, 2009 at 04:59:08PM -0700, Doug Barton wrote: > Can Eugene, Volker, and anyone else affected by this please try this > very-lightly-modified version of the patch and confirm that it works? > If so, I will get this in ASAP. Yes, it works too :-) Thanks. Eugene Grosbein From mksmith at adhost.com Tue Oct 13 00:36:01 2009 From: mksmith at adhost.com (Michael K. Smith) Date: Tue Oct 13 00:36:07 2009 Subject: Wacky DHCP values that work in windows but not in FreeBSD In-Reply-To: <4AD3B9FB.4010205@FreeBSD.org> Message-ID: On 10/12/09 4:21 PM, "Doug Barton" wrote: > Michael K. Smith - Adhost wrote: >>> -----Original Message----- >>> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- >>> net@freebsd.org] On Behalf Of Julian Elischer >>> Sent: Monday, October 12, 2009 4:00 PM >>> To: Doug Barton >>> Cc: freebsd-net@freebsd.org >>> Subject: Re: Wacky DHCP values that work in windows but not in FreeBSD >>> >>> Doug Barton wrote: >>>> Howdy, >>>> >>>> I usually have a wireless router connected directly to the >> AT&T/Yahoo >>>> DSL modem but last night I wanted to do some debugging so I plugged >>> my >>>> laptop directly into the modem (after powering off the modem, etc.). >>>> >>>> The values I got back from DHCP not only don't make sense, they >>> didn't >>>> work in FreeBSD at all. Dual-booting to Windows showed that the >>> values >>>> I saw from DHCP were "correct," and somehow they managed to work. >>>> Taking a closer look at the router after I plugged it back in showed >>>> the same. >>>> >>>> Dhcp Enabled. . . . . . . . . . . : Yes >>>> Autoconfiguration Enabled . . . . : Yes >>>> IP Address. . . . . . . . . . . . : 76.212.147.xxx >>>> Subnet Mask . . . . . . . . . . . : 255.255.0.0 >>>> Default Gateway . . . . . . . . . : 151.164.184.xxx >>> huh? >>> >>> only way this could work would be if it was marked as "point to point" >>> I think.. >> >> That could be a primary IP address on an interface on which your 76 >> address is a sub interface. > > Can you specify what you mean by 'that'? Sure. In Cisco world Interface GigE0/0 Ip address 151.164.184.xxx 255.255.255.252 (or whatever the mask is) Ip addres 76.212.147.1 255.255.0.0 secondary They will use the primary IP address as the default. > >> The interface will do proxy-arp when a >> traffic request comes in. Or something else! I'm not sure if this will >> work, but you could actually hard code your default gateway with a >> -hopcount 2 (or higher) and see if that works. I've not tried it on a >> live machine. Something like route add default 151.164.184.xxx >> -hopcount 5. You may have to delete the DHCP-assigned entry first. > > Ah, I didn't know about -hopcount, thanks. There was no default route > installed at all when I booted. I tried 'route add default 151...' > even though I was sure it wouldn't work, and I was not disappointed. Heh. It probably complained because you weren't on the local network. As Julian mentioned, you may be able to add the -iface should help. Also, if you wanted to test, you could add yourself on the same subnet as the default gateway. Depending on what xxx is on the 151 net, you could add an interface address in the same subnet. As an example, if the address is 50, you could add 49 and a /30 subnet mask. Another trick would be to plug the windows box back in and do an 'arp -an' and find the MAC address for the 151 (if it's available). Then, you can manually add the arp to your FreeBSD box. Mike From dhorn2000 at gmail.com Tue Oct 13 03:30:36 2009 From: dhorn2000 at gmail.com (David Horn) Date: Tue Oct 13 03:30:52 2009 Subject: Wacky DHCP values that work in windows but not in FreeBSD In-Reply-To: <4AD3ABD0.7010603@FreeBSD.org> References: <4AD3ABD0.7010603@FreeBSD.org> Message-ID: <25ff90d60910122030r1f8511e9ued9535024fa3078a@mail.gmail.com> On Mon, Oct 12, 2009 at 6:21 PM, Doug Barton wrote: > Howdy, > > I usually have a wireless router connected directly to the AT&T/Yahoo > DSL modem but last night I wanted to do some debugging so I plugged my > laptop directly into the modem (after powering off the modem, etc.). > > The values I got back from DHCP not only don't make sense, they didn't > work in FreeBSD at all. Dual-booting to Windows showed that the values > I saw from DHCP were "correct," and somehow they managed to work. > Taking a closer look at the router after I plugged it back in showed > the same. > > ? ? ? ?Dhcp Enabled. . . . . . . . . . . : Yes > ? ? ? ?Autoconfiguration Enabled . . . . : Yes > ? ? ? ?IP Address. . . . . . . . . . . . : 76.212.147.xxx > ? ? ? ?Subnet Mask . . . . . . . . . . . : 255.255.0.0 > ? ? ? ?Default Gateway . . . . . . . . . : 151.164.184.xxx > ? ? ? ?DHCP Server . . . . . . . . . . . : 192.168.1.xxx > ? ? ? ?DNS Servers . . . . . . . . . . . : 192.168.1.xxx > > Can anyone tell me how they managed to get this to work in Windows, > and suggest where to look to get it working in FreeBSD? > > > Doug > Without seeing the actual tcpdump of the dhcp packets, I would guess that this is the Classless Static Route option in DHCPv4 (option 121). See: http://www.rfc-editor.org/rfc/rfc3442.txt http://www.iana.org/assignments/bootp-dhcp-parameters/ But tcpdump before dhclient initialization of the interface should show what options are in play (I could be wrong on option 121) tcpdump -vvv -i em0 port bootpc Good Luck. ---Dave H From dougb at FreeBSD.org Tue Oct 13 05:31:57 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Oct 13 05:32:04 2009 Subject: Wacky DHCP values that work in windows but not in FreeBSD In-Reply-To: <25ff90d60910122030r1f8511e9ued9535024fa3078a@mail.gmail.com> References: <4AD3ABD0.7010603@FreeBSD.org> <25ff90d60910122030r1f8511e9ued9535024fa3078a@mail.gmail.com> Message-ID: <4AD410CB.2060105@FreeBSD.org> David Horn wrote: > Without seeing the actual tcpdump of the dhcp packets, I would guess > that this is the Classless Static Route option in DHCPv4 (option 121). Ok, I will give the tcpdump option a go as soon as I have a chance. Meanwhile, if this is in fact the case how would we make it work in FreeBSD? Is there a newer version of DHCP that handles this properly? Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From dhorn2000 at gmail.com Tue Oct 13 05:55:31 2009 From: dhorn2000 at gmail.com (David Horn) Date: Tue Oct 13 05:55:43 2009 Subject: Wacky DHCP values that work in windows but not in FreeBSD In-Reply-To: <4AD410CB.2060105@FreeBSD.org> References: <4AD3ABD0.7010603@FreeBSD.org> <25ff90d60910122030r1f8511e9ued9535024fa3078a@mail.gmail.com> <4AD410CB.2060105@FreeBSD.org> Message-ID: <25ff90d60910122255j5ccae96ar7c58488209768956@mail.gmail.com> On Tue, Oct 13, 2009 at 1:31 AM, Doug Barton wrote: > David Horn wrote: >> Without seeing the actual tcpdump of the dhcp packets, I would guess >> that this is the Classless Static Route option in DHCPv4 (option 121). > > Ok, I will give the tcpdump option a go as soon as I have a chance. > > Meanwhile, if this is in fact the case how would we make it work in > FreeBSD? Is there a newer version of DHCP that handles this properly? I thought that dhclient originated from ISC, but looking at the 4.1.1b2 ISC DHCP source and at the OpenBSD dhclient, I did not see option 121 handling in dhclient. The freebsd copy of both dhclient.c, and /sbin/dhclient-script there is code for handling this option. I guess the FreeBSD version split from the ISC version at some point, and option 121 handling was added (2+ years ago). As far as fixing/debugging, it all depends on the exact dhcp options and values. It might just be a tweak to /sbin/dhclient-script, or it may be more complicated. http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/dhclient/dhclient.c Revision 1.21: download - view: text, markup, annotated - select for diffs Fri Feb 9 17:50:26 2007 UTC (2 years, 8 months ago) by emaste Branches: MAIN CVS tags: RELENG_7_BP, RELENG_7_0_BP, RELENG_7_0_0_RELEASE, RELENG_7_0 Branch point for: RELENG_7 Diff to: previous 1.20: preferred, colored Changes since revision 1.20: +68 -0 lines Implement RFC3442, the Classless Static Route option. The original DHCP specification includes a route option but it supports only class-based routes. RFC3442 adds support for specifying the netmask width for each static route. A variable length encoding is used to minimize the size of this option. PR: bin/99534 Submitted by: Andrey V. Elsukov Reviewed by: brooks ---Dave H From kauselot at yahoo.com Tue Oct 13 08:20:04 2009 From: kauselot at yahoo.com (kause lotski) Date: Tue Oct 13 08:20:10 2009 Subject: kern/137317: [tcp] logs full of syncache problems Message-ID: <200910130820.n9D8K42Y080738@freefall.freebsd.org> The following reply was made to PR kern/137317; it has been noted by GNATS. From: kause lotski To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/137317: [tcp] logs full of syncache problems Date: Tue, 13 Oct 2009 00:43:36 -0700 (PDT) perhaps some more information would help: I'm experiencing this on two different boxes with totally different hardware, one located at datacenter and connected via LAN and second one that is sitting on ADSL line. I have tried all sysctl variables that I could find remotely related to this with no luck, tried compiling kernel with and without DUMMYNET This are kernel customizations I use: options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options DUMMYNET options HZ=1000 # strongly recommended options IPDIVERT options IPSTEALTH #support for stealth forwarding options ACCEPT_FILTER_HTTP # Must be here or AcceptFilter won't work w/Apache2 options DEVICE_POLLING # Imporoves network driver performance options ZERO_COPY_SOCKETS device coretemp # On-die temperature sensor on Intel Core and newer CPUs Is it at least possible to turn of this checks for local IP's - it is most disturbing that I'm getting droped packets at apache jail to mysql jail communication? From linimon at FreeBSD.org Tue Oct 13 13:35:17 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Oct 13 13:35:23 2009 Subject: kern/139559: [tun] several tun(4) interfaces can be created with same dst addr Message-ID: <200910131335.n9DDZGV2060195@freefall.freebsd.org> Old Synopsis: several tun(4) interfaces can be created with same dst addr New Synopsis: [tun] several tun(4) interfaces can be created with same dst addr Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Oct 13 13:34:59 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=139559 From bzeeb-lists at lists.zabbadoz.net Tue Oct 13 20:45:08 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue Oct 13 20:45:15 2009 Subject: testers for bge(4) needed (possible fix for ASF + hang) Message-ID: <20091013203302.N5956@maildrop.int.zabbadoz.net> Hi, this is believed to fix hangs upon boot when the interfaces are configured and ASF is enabled. As seen in the PRs, this is often observed on HP servers. In case you have a bge machine not affected by that it owuld be really helpful if you could test the change anyway to assure this doesn't break any of the several dozen chip revisions we couldn't test. The patch is also fetchable from http://people.freebsd.org/~bz/20091011-01-bge-asf.diff In case it doesn't apply to your older version of the driver cleanly let me know and I'll do a patch for your version as well. In case you find a regression with that let me know immediately with: uname -mr; dmesg | grep bge ; pciconf -lv | grep ^bge Thanks a lot. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ---------- Forwarded message ---------- Date: Tue, 13 Oct 2009 20:22:12 +0000 (UTC) From: Bjoern A. Zeeb To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r198049 - head/sys/dev/bge Author: bz Date: Tue Oct 13 20:22:12 2009 New Revision: 198049 URL: http://svn.freebsd.org/changeset/base/198049 Log: Immediately after clearing a pending callout that didn't make it due to the lock we hold, disable interrupts, and announce to the firmware that we are shutting down. Especially do this before disabling blocks. This makes some types of machines with asf enabled no longer hang upon boot, when we start configuring the interface. PR: i386/96382, kern/100410, kern/122252, kern/116328 Reported by: erwin Hardware provided by: TDC A/S Reviewed by: stas Tested by: stas Modified: head/sys/dev/bge/if_bge.c Modified: head/sys/dev/bge/if_bge.c ============================================================================== --- head/sys/dev/bge/if_bge.c Tue Oct 13 20:21:17 2009 (r198048) +++ head/sys/dev/bge/if_bge.c Tue Oct 13 20:22:12 2009 (r198049) @@ -4270,6 +4270,16 @@ bge_stop(struct bge_softc *sc) callout_stop(&sc->bge_stat_ch); + /* Disable host interrupts. */ + BGE_SETBIT(sc, BGE_PCI_MISC_CTL, BGE_PCIMISCCTL_MASK_PCI_INTR); + bge_writembx(sc, BGE_MBX_IRQ0_LO, 1); + + /* + * Tell firmware we're shutting down. + */ + bge_stop_fw(sc); + bge_sig_pre_reset(sc, BGE_RESET_STOP); + /* * Disable all of the receiver blocks. */ @@ -4309,16 +4319,6 @@ bge_stop(struct bge_softc *sc) BGE_CLRBIT(sc, BGE_MARB_MODE, BGE_MARBMODE_ENABLE); } - /* Disable host interrupts. */ - BGE_SETBIT(sc, BGE_PCI_MISC_CTL, BGE_PCIMISCCTL_MASK_PCI_INTR); - bge_writembx(sc, BGE_MBX_IRQ0_LO, 1); - - /* - * Tell firmware we're shutting down. - */ - - bge_stop_fw(sc); - bge_sig_pre_reset(sc, BGE_RESET_STOP); bge_reset(sc); bge_sig_legacy(sc, BGE_RESET_STOP); bge_sig_post_reset(sc, BGE_RESET_STOP); From simon at comsys.ntu-kpi.kiev.ua Wed Oct 14 11:10:03 2009 From: simon at comsys.ntu-kpi.kiev.ua (Andrey Simonenko) Date: Wed Oct 14 11:10:11 2009 Subject: bin/131567: Update for regression/sockets/unix_cmsg Message-ID: <200910141110.n9EBA3UQ002279@freefall.freebsd.org> The following reply was made to PR bin/131567; it has been noted by GNATS. From: Andrey Simonenko To: bug-followup@freebsd.org Cc: Subject: Re: bin/131567: Update for regression/sockets/unix_cmsg Date: Wed, 14 Oct 2009 14:07:13 +0300 Updated version of the patch for regression/sockets/unix_cmsg has some optimizations and does not use SIGALRM. Can somebody verify whether it is possible to increase WARNS to higher level (I tested unix_cmsg on i386 and amd64 on 8.0-RC1 release)? diff -ruNp unix_cmsg.orig/README unix_cmsg/README --- unix_cmsg.orig/README 2006-05-29 21:40:55.000000000 +0300 +++ unix_cmsg/README 2009-10-14 13:31:06.000000000 +0300 @@ -1,7 +1,7 @@ $FreeBSD: src/tools/regression/sockets/unix_cmsg/README,v 1.1 2006/05/29 18:40:55 maxim Exp $ About unix_cmsg -================ +=============== This program is a collection of regression tests for ancillary (control) data for PF_LOCAL sockets (local domain or Unix domain sockets). There @@ -13,8 +13,8 @@ is correct in received message. Sometim messages to Server. It is better to change the owner of unix_cmsg to some safe user -(eg. nobody:nogroup) and set SUID and SGID bits, else some tests -can give correct results for wrong implementation. +(eg. nobody:nogroup) and set SUID and SGID bits, else some tests that +check credentials can give correct results for wrong implementation. Available options ================= @@ -24,13 +24,13 @@ Available options -h Output help message and exit. --t +-t socktype Run tests only for the given socket type: "stream" or "dgram". With this option it is possible to run only particular test, not all of them. -z Do not send real control data if possible. Struct cmsghdr{} - should be followed by real control data. It is not clear if + should be followed by real control data. It is not clear whether a sender should give control data in all cases (this is not documented and an arbitrary application can choose anything). @@ -90,6 +90,13 @@ For SOCK_STREAM sockets: message with data and control message with SCM_TIMESTAMP type followed by struct timeval{}. + 6: Check LOCAL_PEERCRED socket option + + This test does not use control data for PF_LOCAL sockets, but can be + implemented here. Client connects to Server. Both Client and Server + verify that credentials of the peer are correct using LOCAL_PEERCRED + socket option. + For SOCK_DGRAM sockets: ---------------------- @@ -110,7 +117,7 @@ For SOCK_DGRAM sockets: structure should contain correct information. 3: Sending cmsgcred, receiving sockcred - + Server creates datagram socket and set socket option LOCAL_CREDS for it. Client sends one message with data and control message with SOCK_CREDS type to Server. Server should receive one message with diff -ruNp unix_cmsg.orig/unix_cmsg.c unix_cmsg/unix_cmsg.c --- unix_cmsg.orig/unix_cmsg.c 2006-05-31 11:10:34.000000000 +0300 +++ unix_cmsg/unix_cmsg.c 2009-10-14 13:47:51.000000000 +0300 @@ -27,10 +27,12 @@ #include __FBSDID("$FreeBSD: src/tools/regression/sockets/unix_cmsg/unix_cmsg.c,v 1.2 2006/05/31 08:10:34 maxim Exp $"); -#include +#include #include #include +#include #include +#include #include #include @@ -38,16 +40,15 @@ __FBSDID("$FreeBSD: src/tools/regression #include #include #include +#include #include #include -#include #include #include #include #include #include #include -#include #include /* @@ -68,7 +69,7 @@ __FBSDID("$FreeBSD: src/tools/regression * * Each function which can block, is run under TIMEOUT, if timeout * occurs, then test function returns -2 or a client process exits - * with nonzero return code. + * with non-zero return code. */ #ifndef LISTENQ @@ -76,46 +77,76 @@ __FBSDID("$FreeBSD: src/tools/regression #endif #ifndef TIMEOUT -# define TIMEOUT 60 +# define TIMEOUT 5 #endif #define EXTRA_CMSG_SPACE 512 /* Memory for not expected control data. */ -static int t_cmsgcred(void), t_sockcred_stream1(void); -static int t_sockcred_stream2(void), t_cmsgcred_sockcred(void); -static int t_sockcred_dgram(void), t_timestamp(void); +static int t_cmsgcred(void); +static int t_sockcred_stream1(void); +static int t_sockcred_stream2(void); +static int t_cmsgcred_sockcred(void); +static int t_sockcred_dgram(void); +static int t_timestamp(void); +static int t_peercred(void); struct test_func { - int (*func)(void); /* Pointer to function. */ - const char *desc; /* Test description. */ + int (*func)(void); /* Pointer to function. */ + const char *desc; /* Test description. */ }; static struct test_func test_stream_tbl[] = { - { NULL, " 0: All tests" }, - { t_cmsgcred, " 1: Sending, receiving cmsgcred" }, - { t_sockcred_stream1, " 2: Receiving sockcred (listening socket has LOCAL_CREDS)" }, - { t_sockcred_stream2, " 3: Receiving sockcred (accepted socket has LOCAL_CREDS)" }, - { t_cmsgcred_sockcred, " 4: Sending cmsgcred, receiving sockcred" }, - { t_timestamp, " 5: Sending, receiving timestamp" }, - { NULL, NULL } + { .func = NULL, + .desc = "All tests" + }, + { .func = t_cmsgcred, + .desc = "Sending, receiving cmsgcred" + }, + { .func = t_sockcred_stream1, + .desc = "Receiving sockcred (listening socket has LOCAL_CREDS)" + }, + { .func = t_sockcred_stream2, + .desc = "Receiving sockcred (accepted socket has LOCAL_CREDS)" + }, + { .func = t_cmsgcred_sockcred, + .desc = "Sending cmsgcred, receiving sockcred" + }, + { .func = t_timestamp, + .desc = "Sending, receiving timestamp" + }, + { .func = t_peercred, + .desc = "Check LOCAL_PEERCRED socket option" + } }; +#define TEST_STREAM_TBL_SIZE \ + (sizeof(test_stream_tbl) / sizeof(test_stream_tbl[0])) + static struct test_func test_dgram_tbl[] = { - { NULL, " 0: All tests" }, - { t_cmsgcred, " 1: Sending, receiving cmsgcred" }, - { t_sockcred_dgram, " 2: Receiving sockcred" }, - { t_cmsgcred_sockcred, " 3: Sending cmsgcred, receiving sockcred" }, - { t_timestamp, " 4: Sending, receiving timestamp" }, - { NULL, NULL } + { .func = NULL, + .desc = "All tests" + }, + { .func = t_cmsgcred, + .desc = "Sending, receiving cmsgcred" + }, + { .func = t_sockcred_dgram, + .desc = "Receiving sockcred" + }, + { .func = t_cmsgcred_sockcred, + .desc = "Sending cmsgcred, receiving sockcred" + }, + { .func = t_timestamp, + .desc = "Sending, receiving timestamp" + } }; -#define TEST_STREAM_NO_MAX (sizeof(test_stream_tbl) / sizeof(struct test_func) - 2) -#define TEST_DGRAM_NO_MAX (sizeof(test_dgram_tbl) / sizeof(struct test_func) - 2) +#define TEST_DGRAM_TBL_SIZE \ + (sizeof(test_dgram_tbl) / sizeof(test_dgram_tbl[0])) -static const char *myname = "SERVER"; /* "SERVER" or "CLIENT" */ +static const char *myname; /* "SERVER" or "CLIENT" */ -static int debug = 0; /* 1, if -d. */ -static int no_control_data = 0; /* 1, if -z. */ +static int debug = 0; /* -d */ +static int no_control_data = 0; /* -z */ static u_int nfailed = 0; /* Number of failed tests. */ @@ -131,8 +162,6 @@ static char ipc_message[] = "hello"; static struct sockaddr_un servaddr; /* Server address. */ -static sigjmp_buf env_alrm; - static uid_t my_uid; static uid_t my_euid; static gid_t my_gid; @@ -156,32 +185,29 @@ static void logmsg(const char *, ...) __ static void logmsgx(const char *, ...) __printflike(1, 2); static void output(const char *, ...) __printflike(1, 2); -extern char *__progname; /* The name of program. */ - /* * Output the help message (-h switch). */ static void -usage(int quick) +usage(const int verbose) { - const struct test_func *test_func; + u_int i; - fprintf(stderr, "Usage: %s [-dhz] [-t ] [testno]\n", - __progname); - if (quick) + fprintf(stderr, "usage: %s [-dhz] [-t socktype] [testno]\n", + getprogname()); + if (!verbose) return; fprintf(stderr, "\n Options are:\n\ -d\t\t\tOutput debugging information\n\ -h\t\t\tOutput this help message and exit\n\ - -t \t\tRun test only for the given socket type:\n\ -\t\t\tstream or dgram\n\ + -t socktype\t\tRun test only for socket type: stream or dgram\n\ -z\t\t\tDo not send real control data if possible\n\n"); fprintf(stderr, " Available tests for stream sockets:\n"); - for (test_func = test_stream_tbl; test_func->desc != NULL; ++test_func) - fprintf(stderr, " %s\n", test_func->desc); + for (i = 0; i < TEST_STREAM_TBL_SIZE; ++i) + fprintf(stderr, " %u: %s\n", i, test_stream_tbl[i].desc); fprintf(stderr, "\n Available tests for datagram sockets:\n"); - for (test_func = test_dgram_tbl; test_func->desc != NULL; ++test_func) - fprintf(stderr, " %s\n", test_func->desc); + for (i = 0; i < TEST_DGRAM_TBL_SIZE; ++i) + fprintf(stderr, " %u: %s\n", i, test_dgram_tbl[i].desc); } /* @@ -195,7 +221,7 @@ output(const char *format, ...) va_start(ap, format); if (vsnprintf(buf, sizeof(buf), format, ap) < 0) - err(EX_SOFTWARE, "output: vsnprintf failed"); + err(EXIT_FAILURE, "output: vsnprintf failed"); write(STDOUT_FILENO, buf, strlen(buf)); va_end(ap); } @@ -210,18 +236,16 @@ logmsg(const char *format, ...) va_list ap; int errno_save; - errno_save = errno; /* Save errno. */ - + errno_save = errno; va_start(ap, format); if (vsnprintf(buf, sizeof(buf), format, ap) < 0) - err(EX_SOFTWARE, "logmsg: vsnprintf failed"); + err(EXIT_FAILURE, "logmsg: vsnprintf failed"); if (errno_save == 0) output("%s: %s\n", myname, buf); else output("%s: %s: %s\n", myname, buf, strerror(errno_save)); va_end(ap); - - errno = errno_save; /* Restore errno. */ + errno = errno_save; } /* @@ -235,33 +259,47 @@ logmsgx(const char *format, ...) va_start(ap, format); if (vsnprintf(buf, sizeof(buf), format, ap) < 0) - err(EX_SOFTWARE, "logmsgx: vsnprintf failed"); + err(EXIT_FAILURE, "logmsgx: vsnprintf failed"); output("%s: %s\n", myname, buf); va_end(ap); } /* - * Run tests from testno1 to testno2. + * Run tests for the given socket type. */ static int -run_tests(u_int testno1, u_int testno2) +run_tests(const int type, u_int testno1) { - const struct test_func *test_func; - u_int i, nfailed1; + const struct test_func *tf; + u_int i, nfailed1, testno2; - output("Running tests for %s sockets:\n", sock_type_str); - test_func = (sock_type == SOCK_STREAM ? - test_stream_tbl : test_dgram_tbl) + testno1; + sock_type = type; + if (type == SOCK_STREAM) { + sock_type_str = "SOCK_STREAM"; + tf = test_stream_tbl; + i = TEST_STREAM_TBL_SIZE - 1; + } else { + sock_type_str = "SOCK_DGRAM"; + tf = test_dgram_tbl; + i = TEST_DGRAM_TBL_SIZE - 1; + } + if (testno1 == 0) { + testno1 = 1; + testno2 = i; + } else + testno2 = testno1; + output("Running tests for %s sockets:\n", sock_type_str); nfailed1 = 0; - for (i = testno1; i <= testno2; ++test_func, ++i) { - output(" %s\n", test_func->desc); - switch (test_func->func()) { + for (i = testno1, tf += testno1; i <= testno2; ++tf, ++i) { + output(" %u: %s\n", i, tf->desc); + switch (tf->func()) { case -1: ++nfailed1; break; case -2: - logmsgx("some system error occurred, exiting"); + logmsgx("some system error or timeout occurred, " + "exiting"); return (-1); } } @@ -284,38 +322,40 @@ run_tests(u_int testno1, u_int testno2) return (0); } -/* ARGSUSED */ -static void -sig_alrm(int signo __unused) -{ - siglongjmp(env_alrm, 1); -} - /* * Initialize signals handlers. */ static void sig_init(void) { - struct sigaction sa; + struct sigaction sigact; + + sigact.sa_handler = SIG_IGN; + sigact.sa_flags = 0; + sigemptyset(&sigact.sa_mask); + if (sigaction(SIGPIPE, &sigact, (struct sigaction *)NULL) < 0) + err(EXIT_FAILURE, "sigaction(SIGPIPE)"); +} - sa.sa_handler = SIG_IGN; - sigemptyset(&sa.sa_mask); - sa.sa_flags = 0; - if (sigaction(SIGPIPE, &sa, (struct sigaction *)NULL) < 0) - err(EX_OSERR, "sigaction(SIGPIPE)"); - - sa.sa_handler = sig_alrm; - if (sigaction(SIGALRM, &sa, (struct sigaction *)NULL) < 0) - err(EX_OSERR, "sigaction(SIGALRM)"); +static int +fork_client(void) +{ + client_pid = fork(); + if (client_pid == 0) + myname = "CLIENT"; + else if (client_pid == (pid_t)-1) { + logmsg("fork"); + return (-1); + } + return (0); } int main(int argc, char *argv[]) { const char *errstr; - int opt, dgramflag, streamflag; - u_int testno1, testno2; + u_int testno; + int opt, rv, dgramflag, streamflag; dgramflag = streamflag = 0; while ((opt = getopt(argc, argv, "dht:z")) != -1) @@ -324,141 +364,162 @@ main(int argc, char *argv[]) debug = 1; break; case 'h': - usage(0); - return (EX_OK); + usage(1); + return (EXIT_SUCCESS); case 't': if (strcmp(optarg, "stream") == 0) streamflag = 1; else if (strcmp(optarg, "dgram") == 0) dgramflag = 1; else - errx(EX_USAGE, "wrong socket type in -t option"); + errx(EXIT_FAILURE, "option -t: wrong " + "socket type"); break; case 'z': no_control_data = 1; break; case '?': default: - usage(1); - return (EX_USAGE); + usage(0); + return (EXIT_FAILURE); } if (optind < argc) { if (optind + 1 != argc) - errx(EX_USAGE, "too many arguments"); - testno1 = strtonum(argv[optind], 0, UINT_MAX, &errstr); + errx(EXIT_FAILURE, "too many arguments"); + testno = strtonum(argv[optind], 0, UINT_MAX, &errstr); if (errstr != NULL) - errx(EX_USAGE, "wrong test number: %s", errstr); + errx(EXIT_FAILURE, "wrong test number: %s", errstr); } else - testno1 = 0; + testno = 0; if (dgramflag == 0 && streamflag == 0) dgramflag = streamflag = 1; - if (dgramflag && streamflag && testno1 != 0) - errx(EX_USAGE, "you can use particular test, only with datagram or stream sockets"); + if (dgramflag && streamflag && testno != 0) + errx(EXIT_FAILURE, "you can use particular test, only " + "with datagram or stream sockets"); if (streamflag) { - if (testno1 > TEST_STREAM_NO_MAX) - errx(EX_USAGE, "given test %u for stream sockets does not exist", - testno1); + if (testno >= TEST_STREAM_TBL_SIZE) + errx(EXIT_FAILURE, "given test %u for stream " + "sockets does not exist", testno); } else { - if (testno1 > TEST_DGRAM_NO_MAX) - errx(EX_USAGE, "given test %u for datagram sockets does not exist", - testno1); + if (testno >= TEST_DGRAM_TBL_SIZE) + errx(EXIT_FAILURE, "given test %u for datagram " + "sockets does not exist", testno); } my_uid = getuid(); my_euid = geteuid(); my_gid = getgid(); my_egid = getegid(); - switch (my_ngids = getgroups(sizeof(my_gids) / sizeof(my_gids[0]), my_gids)) { + my_ngids = getgroups(sizeof(my_gids) / sizeof(my_gids[0]), my_gids); + switch (my_ngids) { case -1: - err(EX_SOFTWARE, "getgroups"); + err(EXIT_FAILURE, "getgroups"); /* NOTREACHED */ case 0: - errx(EX_OSERR, "getgroups returned 0 groups"); + errx(EXIT_FAILURE, "getgroups returned no groups"); } sig_init(); if (mkdtemp(tempdir) == NULL) - err(EX_OSERR, "mkdtemp"); + err(EXIT_FAILURE, "mkdtemp"); - if (streamflag) { - sock_type = SOCK_STREAM; - sock_type_str = "SOCK_STREAM"; - if (testno1 == 0) { - testno1 = 1; - testno2 = TEST_STREAM_NO_MAX; - } else - testno2 = testno1; - if (run_tests(testno1, testno2) < 0) - goto failed; - testno1 = 0; - } - - if (dgramflag) { - sock_type = SOCK_DGRAM; - sock_type_str = "SOCK_DGRAM"; - if (testno1 == 0) { - testno1 = 1; - testno2 = TEST_DGRAM_NO_MAX; - } else - testno2 = testno1; - if (run_tests(testno1, testno2) < 0) - goto failed; - } + myname = "SERVER"; + rv = EXIT_SUCCESS; + if (streamflag) + if (run_tests(SOCK_STREAM, testno) < 0) + rv = EXIT_FAILURE; + if (dgramflag && rv == EXIT_SUCCESS) + if (run_tests(SOCK_DGRAM, testno) < 0) + rv = EXIT_FAILURE; if (rmdir(tempdir) < 0) { logmsg("rmdir(%s)", tempdir); - return (EX_OSERR); + rv = EXIT_FAILURE; } - return (nfailed ? EX_OSERR : EX_OK); + return (nfailed > 0 ? EXIT_FAILURE : rv); +} -failed: - if (rmdir(tempdir) < 0) - logmsg("rmdir(%s)", tempdir); - return (EX_OSERR); +/* + * Close socket descriptor, if sock_path is not equal to NULL, + * then unlink the given path. + */ +static int +close_socket(const char *sock_path, const int fd) +{ + int rv; + + if (close(fd) < 0) { + logmsg("close_socket: close"); + rv = -1; + } else + rv = 0; + if (sock_path != NULL) + if (unlink(sock_path) < 0) { + logmsg("close_socket: unlink(%s)", sock_path); + rv = -1; + } + return (rv); } /* * Create PF_LOCAL socket, if sock_path is not equal to NULL, then - * bind() it. Return socket address in addr. Return file descriptor + * bind() it. Return socket address in *un. Return file descriptor * or -1 if some error occurred. */ static int -create_socket(char *sock_path, size_t sock_path_len, struct sockaddr_un *addr) +create_socket(char *sock_path, const size_t sock_path_len, + struct sockaddr_un *un) { - int rv, fd; + struct timeval tv; + int fd; - if ((fd = socket(PF_LOCAL, sock_type, 0)) < 0) { - logmsg("create_socket: socket(PF_LOCAL, %s, 0)", sock_type_str); + fd = socket(PF_LOCAL, sock_type, 0); + if (fd < 0) { + logmsg("create_socket: socket(PF_LOCAL, %s, 0)", + sock_type_str); return (-1); } + tv.tv_sec = TIMEOUT; + tv.tv_usec = 0; + if (setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv)) < 0 || + setsockopt(fd, SOL_SOCKET, SO_SNDTIMEO, &tv, sizeof(tv)) < 0) { + logmsg("create_socket: setsockopt(SO_RCVTIMEO/SO_SNDTIMEO)"); + goto failed; + } + if (sock_path != NULL) { - if ((rv = snprintf(sock_path, sock_path_len, "%s/%s", - tempdir, myname)) < 0) { + int rv; + + rv = snprintf(sock_path, sock_path_len, "%s/%s", tempdir, + myname); + if (rv < 0) { logmsg("create_socket: snprintf failed"); goto failed; } if ((size_t)rv >= sock_path_len) { - logmsgx("create_socket: too long path name for given buffer"); + logmsgx("create_socket: too long path name for " + "given buffer"); goto failed; } - - memset(addr, 0, sizeof(addr)); - addr->sun_family = AF_LOCAL; - if (strlen(sock_path) >= sizeof(addr->sun_path)) { - logmsgx("create_socket: too long path name (>= %lu) for local domain socket", - (u_long)sizeof(addr->sun_path)); + if (strlen(sock_path) >= sizeof(un->sun_path)) { + logmsgx("create_socket: too long path name (>= %zu) " + "for local domain socket", sizeof(un->sun_path)); goto failed; } - strcpy(addr->sun_path, sock_path); - if (bind(fd, (struct sockaddr *)addr, SUN_LEN(addr)) < 0) { + memset(un, 0, sizeof(un)); + un->sun_family = PF_LOCAL; + strcpy(un->sun_path, sock_path); + un->sun_len = SUN_LEN(un); + + if (bind(fd, (struct sockaddr *)un, un->sun_len) < 0) { logmsg("create_socket: bind(%s)", sock_path); goto failed; } @@ -473,43 +534,49 @@ failed: } /* - * Call create_socket() for server listening socket. - * Return socket descriptor or -1 if some error occurred. + * Create server socket. */ static int create_server_socket(void) { - return (create_socket(serv_sock_path, sizeof(serv_sock_path), &servaddr)); -} + int fd; -/* - * Create unbound socket. - */ -static int -create_unbound_socket(void) -{ - return (create_socket((char *)NULL, 0, (struct sockaddr_un *)NULL)); + fd = create_socket(serv_sock_path, sizeof(serv_sock_path), &servaddr); + if (fd < 0) + return (-1); + + if (sock_type == SOCK_STREAM) { + int val; + + if (listen(fd, LISTENQ) < 0) { + logmsg("create_server_socket: listen"); + goto failed; + } + val = fcntl(fd, F_GETFL, 0); + if (val < 0) { + logmsg("create_server_socket: fcntl(F_GETFL)"); + goto failed; + } + if (fcntl(fd, F_SETFL, val | O_NONBLOCK) < 0) { + logmsg("create_server_socket: fcntl(F_SETFL)"); + goto failed; + } + } + + return (fd); + +failed: + (void)close_socket(serv_sock_path, fd); + return (-1); } /* - * Close socket descriptor, if sock_path is not equal to NULL, - * then unlink the given path. + * Create client socket. */ static int -close_socket(const char *sock_path, int fd) +create_client_socket(void) { - int error = 0; - - if (close(fd) < 0) { - logmsg("close_socket: close"); - error = -1; - } - if (sock_path != NULL) - if (unlink(sock_path) < 0) { - logmsg("close_socket: unlink(%s)", sock_path); - error = -1; - } - return (error); + return (create_socket((char *)NULL, 0, (struct sockaddr_un *)NULL)); } /* @@ -524,7 +591,7 @@ connect_server(int fd) * If PF_LOCAL listening socket's queue is full, then connect() * returns ECONNREFUSED immediately, do not need timeout. */ - if (connect(fd, (struct sockaddr *)&servaddr, sizeof(servaddr)) < 0) { + if (connect(fd, (struct sockaddr *)&servaddr, servaddr.sun_len) < 0) { logmsg("connect_server: connect(%s)", serv_sock_path); return (-1); } @@ -533,34 +600,23 @@ connect_server(int fd) } /* - * sendmsg() with timeout. + * sendmsg() wrapper. */ static int -sendmsg_timeout(int fd, struct msghdr *msg, size_t n) +send_message(const int fd, const struct msghdr *msg, const size_t n) { ssize_t nsent; - dbgmsg(("sending %lu bytes", (u_long)n)); - - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("sendmsg_timeout: cannot send message to %s (timeout)", serv_sock_path); - return (-1); - } - - (void)alarm(TIMEOUT); + dbgmsg(("sending %zu bytes", n)); nsent = sendmsg(fd, msg, 0); - - (void)alarm(0); - if (nsent < 0) { - logmsg("sendmsg_timeout: sendmsg"); + logmsg("send_message: sendmsg"); return (-1); } - if ((size_t)nsent != n) { - logmsgx("sendmsg_timeout: sendmsg: short send: %ld of %lu bytes", - (long)nsent, (u_long)n); + logmsgx("send_message: sendmsg: short send: " + "%zd of %zu bytes", nsent, n); return (-1); } @@ -568,63 +624,73 @@ sendmsg_timeout(int fd, struct msghdr *m } /* - * accept() with timeout. + * accept() wrapper. */ static int -accept_timeout(int listenfd) +accept_connection(const int listenfd) { - int fd; + fd_set rset; + struct timeval tv; + int fd, rv, val; dbgmsg(("accepting connection")); - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("accept_timeout: cannot accept connection (timeout)"); + FD_ZERO(&rset); + FD_SET(listenfd, &rset); + tv.tv_sec = TIMEOUT; + tv.tv_usec = 0; + rv = select(listenfd + 1, &rset, (fd_set *)NULL, (fd_set *)NULL, &tv); + if (rv < 0) { + logmsg("accept_connection: select"); + return (-1); + } + if (rv == 0) { + logmsgx("accept_connection: select timeout"); return (-1); } - - (void)alarm(TIMEOUT); fd = accept(listenfd, (struct sockaddr *)NULL, (socklen_t *)NULL); - - (void)alarm(0); - if (fd < 0) { - logmsg("accept_timeout: accept"); + logmsg("accept_connection: accept"); return (-1); } + val = fcntl(fd, F_GETFL, 0); + if (val < 0) { + logmsg("accept_connection: fcntl(F_GETFL)"); + goto failed; + } + if (fcntl(fd, F_SETFL, val & ~O_NONBLOCK) < 0) { + logmsg("accept_connection: fcntl(F_SETFL)"); + goto failed; + } + return (fd); + +failed: + if (close(fd) < 0) + logmsg("accept_connection: close"); + return (-1); } /* - * recvmsg() with timeout. + * recvmsg() wrapper. */ static int -recvmsg_timeout(int fd, struct msghdr *msg, size_t n) +recv_message(const int fd, struct msghdr *msg, const size_t n) { ssize_t nread; - dbgmsg(("receiving %lu bytes", (u_long)n)); - - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("recvmsg_timeout: cannot receive message (timeout)"); - return (-1); - } - - (void)alarm(TIMEOUT); + dbgmsg(("receiving %zu bytes", n)); nread = recvmsg(fd, msg, MSG_WAITALL); - - (void)alarm(0); - if (nread < 0) { - logmsg("recvmsg_timeout: recvmsg"); + logmsg("recv_message: recvmsg"); return (-1); } - if ((size_t)nread != n) { - logmsgx("recvmsg_timeout: recvmsg: short read: %ld of %lu bytes", - (long)nread, (u_long)n); + logmsgx("recv_message: recvmsg: short read: " + "%zd of %zu bytes", nread, n); return (-1); } @@ -632,35 +698,23 @@ recvmsg_timeout(int fd, struct msghdr *m } /* - * Wait for synchronization message (1 byte) with timeout. + * Wait for synchronization message (1 byte). */ static int -sync_recv(int fd) +sync_recv(const int fd) { ssize_t nread; char buf; dbgmsg(("waiting for sync message")); - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("sync_recv: cannot receive sync message (timeout)"); - return (-1); - } - - (void)alarm(TIMEOUT); - nread = read(fd, &buf, 1); - - (void)alarm(0); - if (nread < 0) { logmsg("sync_recv: read"); return (-1); } - if (nread != 1) { - logmsgx("sync_recv: read: short read: %ld of 1 byte", - (long)nread); + logmsgx("sync_recv: read: short read: %zd of 1 byte", nread); return (-1); } @@ -668,34 +722,22 @@ sync_recv(int fd) } /* - * Send synchronization message (1 byte) with timeout. + * Send synchronization message (1 byte). */ static int -sync_send(int fd) +sync_send(const int fd) { ssize_t nsent; dbgmsg(("sending sync message")); - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("sync_send: cannot send sync message (timeout)"); - return (-1); - } - - (void)alarm(TIMEOUT); - nsent = write(fd, "", 1); - - (void)alarm(0); - if (nsent < 0) { logmsg("sync_send: write"); return (-1); } - if (nsent != 1) { - logmsgx("sync_send: write: short write: %ld of 1 byte", - (long)nsent); + logmsgx("sync_send: write: short write: %zd of 1 byte", nsent); return (-1); } @@ -711,36 +753,29 @@ wait_client(void) int status; pid_t pid; - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("wait_client: cannot get exit status of client PID %ld (timeout)", - (long)client_pid); - return (-1); - } - - (void)alarm(TIMEOUT); + dbgmsg(("waiting for a client")); pid = waitpid(client_pid, &status, 0); - - (void)alarm(0); - if (pid == (pid_t)-1) { logmsg("wait_client: waitpid"); return (-1); } if (WIFEXITED(status)) { - if (WEXITSTATUS(status) != 0) { - logmsgx("wait_client: exit status of client PID %ld is %d", - (long)client_pid, WEXITSTATUS(status)); + if (WEXITSTATUS(status) != EXIT_SUCCESS) { + logmsgx("wait_client: exit status of client PID %ld " + "is %d", (long)client_pid, WEXITSTATUS(status)); return (-1); } } else { if (WIFSIGNALED(status)) - logmsgx("wait_client: abnormal termination of client PID %ld, signal %d%s", - (long)client_pid, WTERMSIG(status), WCOREDUMP(status) ? " (core file generated)" : ""); + logmsgx("wait_client: abnormal termination of client " + "PID %ld, signal %d%s", (long)client_pid, + WTERMSIG(status), WCOREDUMP(status) ? + " (core file generated)" : ""); else - logmsgx("wait_client: termination of client PID %ld, unknown status", - (long)client_pid); + logmsgx("wait_client: termination of client PID %ld, " + "unknown status", (long)client_pid); return (-1); } @@ -752,24 +787,24 @@ wait_client(void) * has (my_ngids - 1) supplementary GIDs of current process. */ static int -check_groups(const gid_t *gids, int n) +check_groups(const gid_t *gids, const int n) { + int i, j, rv; char match[NGROUPS_MAX] = { 0 }; - int error, i, j; if (n != my_ngids - 1) { - logmsgx("wrong number of groups %d != %d (returned from getgroups() - 1)", - n, my_ngids - 1); - error = -1; + logmsgx("wrong number of groups %d != %d (returned from " + "getgroups() - 1)", n, my_ngids - 1); + rv = -1; } else - error = 0; + rv = 0; for (i = 0; i < n; ++i) { for (j = 1; j < my_ngids; ++j) { if (gids[i] == my_gids[j]) { if (match[j]) { logmsgx("duplicated GID %lu", (u_long)gids[i]); - error = -1; + rv = -1; } else match[j] = 1; break; @@ -777,15 +812,16 @@ check_groups(const gid_t *gids, int n) } if (j == my_ngids) { logmsgx("unexpected GID %lu", (u_long)gids[i]); - error = -1; + rv = -1; } } for (j = 1; j < my_ngids; ++j) if (match[j] == 0) { - logmsgx("did not receive supplementary GID %u", my_gids[j]); - error = -1; + logmsgx("did not receive supplementary GID %lu", + (u_long)my_gids[j]); + rv = -1; } - return (error); + return (rv); } /* @@ -793,7 +829,7 @@ check_groups(const gid_t *gids, int n) * to server and exit. */ static void -t_cmsgcred_client(u_int n) +t_cmsgcred_client(const u_int n) { union { struct cmsghdr cm; @@ -802,16 +838,19 @@ t_cmsgcred_client(u_int n) struct msghdr msg; struct iovec iov[1]; struct cmsghdr *cmptr; - int fd; u_int i; + int fd, rv; assert(n == 1 || n == 2); - if ((fd = create_unbound_socket()) < 0) + rv = EXIT_FAILURE; + + fd = create_client_socket(); + if (fd < 0) goto failed; if (connect_server(fd) < 0) - goto failed_close; + goto done; iov[0].iov_base = ipc_message; iov[0].iov_len = IPC_MESSAGE_SIZE; @@ -834,20 +873,16 @@ t_cmsgcred_client(u_int n) for (i = 0; i < n; ++i) { dbgmsg(("#%u msg_controllen = %u, cmsg_len = %u", i, (u_int)msg.msg_controllen, (u_int)cmptr->cmsg_len)); - if (sendmsg_timeout(fd, &msg, IPC_MESSAGE_SIZE) < 0) - goto failed_close; + if (send_message(fd, &msg, IPC_MESSAGE_SIZE) < 0) + goto done; } - if (close_socket((const char *)NULL, fd) < 0) - goto failed; - - _exit(0); - -failed_close: - (void)close_socket((const char *)NULL, fd); - + rv = EXIT_SUCCESS; +done: + if (close_socket((char *)NULL, fd)) + rv = EXIT_FAILURE; failed: - _exit(1); + _exit(rv); } /* @@ -856,30 +891,29 @@ failed: * socket for stream sockets or simply socket for datagram sockets. */ static int -t_cmsgcred_server(int fd1) +t_cmsgcred_server(const int fd1) { - char buf[IPC_MESSAGE_SIZE]; union { struct cmsghdr cm; - char control[CMSG_SPACE(sizeof(struct cmsgcred)) + EXTRA_CMSG_SPACE]; + char control[CMSG_SPACE(sizeof(struct cmsgcred)) + + EXTRA_CMSG_SPACE]; } control_un; struct msghdr msg; struct iovec iov[1]; struct cmsghdr *cmptr; - const struct cmsgcred *cmcredptr; - socklen_t controllen; - int error, error2, fd2; + const struct cmsgcred *cmcred; u_int i; + int fd2, rv; + char buf[IPC_MESSAGE_SIZE]; if (sock_type == SOCK_STREAM) { - if ((fd2 = accept_timeout(fd1)) < 0) + fd2 = accept_connection(fd1); + if (fd2 < 0) return (-2); } else fd2 = fd1; - error = 0; - - controllen = sizeof(control_un.control); + rv = 0; for (i = 0; i < 2; ++i) { iov[0].iov_base = buf; @@ -890,29 +924,31 @@ t_cmsgcred_server(int fd1) msg.msg_iov = iov; msg.msg_iovlen = 1; msg.msg_control = control_un.control; - msg.msg_controllen = controllen; + msg.msg_controllen = sizeof(control_un.control); msg.msg_flags = 0; - controllen = CMSG_SPACE(sizeof(struct cmsgcred)); - - if (recvmsg_timeout(fd2, &msg, sizeof(buf)) < 0) - goto failed; + if (recv_message(fd2, &msg, sizeof(buf)) < 0) { + rv = -2; + break; + } if (msg.msg_flags & MSG_CTRUNC) { - logmsgx("#%u control data was truncated, MSG_CTRUNC flag is on", - i); - goto next_error; + logmsgx("#%u control data was truncated, MSG_CTRUNC " + "flag is on", i); + goto next; } if (msg.msg_controllen < sizeof(struct cmsghdr)) { - logmsgx("#%u msg_controllen %u < %lu (sizeof(struct cmsghdr))", - i, (u_int)msg.msg_controllen, (u_long)sizeof(struct cmsghdr)); - goto next_error; + logmsgx("#%u msg_controllen %u < %zu " + "(sizeof(struct cmsghdr))", i, + (u_int)msg.msg_controllen, sizeof(struct cmsghdr)); + goto next; } - if ((cmptr = CMSG_FIRSTHDR(&msg)) == NULL) { + cmptr = CMSG_FIRSTHDR(&msg); + if (cmptr == NULL) { logmsgx("CMSG_FIRSTHDR is NULL"); - goto next_error; + goto next; } dbgmsg(("#%u msg_controllen = %u, cmsg_len = %u", i, @@ -921,166 +957,147 @@ t_cmsgcred_server(int fd1) if (cmptr->cmsg_level != SOL_SOCKET) { logmsgx("#%u cmsg_level %d != SOL_SOCKET", i, cmptr->cmsg_level); - goto next_error; + goto next; } if (cmptr->cmsg_type != SCM_CREDS) { logmsgx("#%u cmsg_type %d != SCM_CREDS", i, cmptr->cmsg_type); - goto next_error; + goto next; } if (cmptr->cmsg_len != CMSG_LEN(sizeof(struct cmsgcred))) { - logmsgx("#%u cmsg_len %u != %lu (CMSG_LEN(sizeof(struct cmsgcred))", - i, (u_int)cmptr->cmsg_len, (u_long)CMSG_LEN(sizeof(struct cmsgcred))); - goto next_error; + logmsgx("#%u cmsg_len %u != %zu " + "(CMSG_LEN(sizeof(struct cmsgcred))", i, + (u_int)cmptr->cmsg_len, + CMSG_LEN(sizeof(struct cmsgcred))); + goto next; } - cmcredptr = (const struct cmsgcred *)CMSG_DATA(cmptr); + cmcred = (struct cmsgcred *)CMSG_DATA(cmptr); - error2 = 0; - if (cmcredptr->cmcred_pid != client_pid) { + if (cmcred->cmcred_pid != client_pid) { logmsgx("#%u cmcred_pid %ld != %ld (PID of client)", - i, (long)cmcredptr->cmcred_pid, (long)client_pid); - error2 = 1; + i, (long)cmcred->cmcred_pid, (long)client_pid); + goto next; } - if (cmcredptr->cmcred_uid != my_uid) { - logmsgx("#%u cmcred_uid %lu != %lu (UID of current process)", - i, (u_long)cmcredptr->cmcred_uid, (u_long)my_uid); - error2 = 1; - } - if (cmcredptr->cmcred_euid != my_euid) { - logmsgx("#%u cmcred_euid %lu != %lu (EUID of current process)", - i, (u_long)cmcredptr->cmcred_euid, (u_long)my_euid); - error2 = 1; - } - if (cmcredptr->cmcred_gid != my_gid) { - logmsgx("#%u cmcred_gid %lu != %lu (GID of current process)", - i, (u_long)cmcredptr->cmcred_gid, (u_long)my_gid); - error2 = 1; + if (cmcred->cmcred_uid != my_uid) { + logmsgx("#%u cmcred_uid %lu != %lu (UID of current " + "process)", i, (u_long)cmcred->cmcred_uid, + (u_long)my_uid); + goto next; + } + if (cmcred->cmcred_euid != my_euid) { + logmsgx("#%u cmcred_euid %lu != %lu (EUID of current " + "process)", i, (u_long)cmcred->cmcred_euid, + (u_long)my_euid); + goto next; + } + if (cmcred->cmcred_gid != my_gid) { + logmsgx("#%u cmcred_gid %lu != %lu (GID of current " + "process)", i, (u_long)cmcred->cmcred_gid, + (u_long)my_gid); + goto next; } - if (cmcredptr->cmcred_ngroups == 0) { + if (cmcred->cmcred_ngroups == 0) { logmsgx("#%u cmcred_ngroups = 0, this is wrong", i); - error2 = 1; - } else { - if (cmcredptr->cmcred_ngroups > NGROUPS_MAX) { - logmsgx("#%u cmcred_ngroups %d > %u (NGROUPS_MAX)", - i, cmcredptr->cmcred_ngroups, NGROUPS_MAX); - error2 = 1; - } else if (cmcredptr->cmcred_ngroups < 0) { - logmsgx("#%u cmcred_ngroups %d < 0", - i, cmcredptr->cmcred_ngroups); - error2 = 1; - } else { - dbgmsg(("#%u cmcred_ngroups = %d", i, - cmcredptr->cmcred_ngroups)); - if (cmcredptr->cmcred_groups[0] != my_egid) { - logmsgx("#%u cmcred_groups[0] %lu != %lu (EGID of current process)", - i, (u_long)cmcredptr->cmcred_groups[0], (u_long)my_egid); - error2 = 1; - } - if (check_groups(cmcredptr->cmcred_groups + 1, cmcredptr->cmcred_ngroups - 1) < 0) { - logmsgx("#%u cmcred_groups has wrong GIDs", i); - error2 = 1; - } - } + goto next; } - - if (error2) - goto next_error; - - if ((cmptr = CMSG_NXTHDR(&msg, cmptr)) != NULL) { - logmsgx("#%u control data has extra header", i); - goto next_error; + if (cmcred->cmcred_ngroups > NGROUPS_MAX) { + logmsgx("#%u cmcred_ngroups %d > %u (NGROUPS_MAX)", + i, cmcred->cmcred_ngroups, NGROUPS_MAX); + goto next; + } + if (cmcred->cmcred_ngroups < 0) { + logmsgx("#%u cmcred_ngroups %d < 0", i, + cmcred->cmcred_ngroups); + goto next; + } + + dbgmsg(("#%u cmcred_ngroups = %d", i, cmcred->cmcred_ngroups)); + if (cmcred->cmcred_groups[0] != my_egid) { + logmsgx("#%u cmcred_groups[0] %lu != %lu (EGID of " + "current process)", i, + (u_long)cmcred->cmcred_groups[0], (u_long)my_egid); + goto next; + } + if (check_groups(cmcred->cmcred_groups + 1, + cmcred->cmcred_ngroups - 1) < 0) { + logmsgx("#%u cmcred_groups has wrong GIDs", i); + goto next; + } + + if (CMSG_NXTHDR(&msg, cmptr) != NULL) { + logmsgx("#%u control data has extra header, this is " + "wrong", i); + goto next; } - continue; -next_error: - error = -1; +next: + rv = -1; } if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) { - logmsg("close"); - return (-2); - } - return (error); - -failed: - if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) - logmsg("close"); - return (-2); + if (close_socket((char *)NULL, fd2) < 0) + rv = -2; + return (rv); } static int t_cmsgcred(void) { - int error, fd; + int fd, rv; - if ((fd = create_server_socket()) < 0) + fd = create_server_socket(); + if (fd < 0) return (-2); - if (sock_type == SOCK_STREAM) - if (listen(fd, LISTENQ) < 0) { - logmsg("listen"); - goto failed; - } + rv = -2; - if ((client_pid = fork()) == (pid_t)-1) { - logmsg("fork"); - goto failed; - } + if (fork_client() < 0) + goto done; if (client_pid == 0) { - myname = "CLIENT"; - if (close_socket((const char *)NULL, fd) < 0) + if (close_socket((char *)NULL, fd) < 0) _exit(1); t_cmsgcred_client(2); } - if ((error = t_cmsgcred_server(fd)) == -2) { - (void)wait_client(); - goto failed; - } + rv = t_cmsgcred_server(fd); if (wait_client() < 0) - goto failed; - - if (close_socket(serv_sock_path, fd) < 0) { - logmsgx("close_socket failed"); - return (-2); - } - return (error); - -failed: + rv = -2; +done: if (close_socket(serv_sock_path, fd) < 0) - logmsgx("close_socket failed"); - return (-2); + rv = -2; + return (rv); } /* * Send two messages with data to server and exit. */ static void -t_sockcred_client(int type) +t_sockcred_client(const int type) { struct msghdr msg; struct iovec iov[1]; - int fd; u_int i; + int fd, rv; assert(type == 0 || type == 1); - if ((fd = create_unbound_socket()) < 0) + rv = EXIT_FAILURE; + + fd = create_client_socket(); + if (fd < 0) goto failed; if (connect_server(fd) < 0) - goto failed_close; + goto done; if (type == 1) if (sync_recv(fd) < 0) - goto failed_close; + goto done; iov[0].iov_base = ipc_message; iov[0].iov_len = IPC_MESSAGE_SIZE; @@ -1094,19 +1111,15 @@ t_sockcred_client(int type) msg.msg_flags = 0; for (i = 0; i < 2; ++i) - if (sendmsg_timeout(fd, &msg, IPC_MESSAGE_SIZE) < 0) - goto failed_close; - - if (close_socket((const char *)NULL, fd) < 0) - goto failed; - - _exit(0); - -failed_close: - (void)close_socket((const char *)NULL, fd); + if (send_message(fd, &msg, IPC_MESSAGE_SIZE) < 0) + goto done; + rv = EXIT_SUCCESS; +done: + if (close_socket((char *)NULL, fd) < 0) + rv = EXIT_FAILURE; failed: - _exit(1); + _exit(rv); } /* @@ -1117,234 +1130,219 @@ failed: * 1, then set LOCAL_CREDS option for accepted stream socket. */ static int -t_sockcred_server(int type, int fd1, u_int n) +t_sockcred_server(const int type, const int fd1, const u_int n) { - char buf[IPC_MESSAGE_SIZE]; union { struct cmsghdr cm; - char control[CMSG_SPACE(SOCKCREDSIZE(NGROUPS_MAX)) + EXTRA_CMSG_SPACE]; + char control[CMSG_SPACE(SOCKCREDSIZE(NGROUPS_MAX)) + + EXTRA_CMSG_SPACE]; } control_un; struct msghdr msg; struct iovec iov[1]; struct cmsghdr *cmptr; const struct sockcred *sockcred; - int error, error2, fd2, optval; u_int i; + int fd2, rv, optval; + char buf[IPC_MESSAGE_SIZE]; assert(n == 1 || n == 2); assert(type == 0 || type == 1); + rv = -2; + if (sock_type == SOCK_STREAM) { - if ((fd2 = accept_timeout(fd1)) < 0) + fd2 = accept_connection(fd1); + if (fd2 < 0) return (-2); if (type == 1) { optval = 1; - if (setsockopt(fd2, 0, LOCAL_CREDS, &optval, sizeof optval) < 0) { - logmsg("setsockopt(LOCAL_CREDS) for accepted socket"); - if (errno == ENOPROTOOPT) { - error = -1; - goto done_close; - } - goto failed; + if (setsockopt(fd2, 0, LOCAL_CREDS, &optval, + sizeof(optval)) < 0) { + logmsg("setsockopt(LOCAL_CREDS) for accepted " + "socket"); + if (errno == ENOPROTOOPT) + rv = -1; + goto done; } if (sync_send(fd2) < 0) - goto failed; + goto done; } } else fd2 = fd1; - error = 0; + rv = 0; for (i = 0; i < n; ++i) { iov[0].iov_base = buf; - iov[0].iov_len = sizeof buf; + iov[0].iov_len = sizeof(buf); msg.msg_name = NULL; msg.msg_namelen = 0; msg.msg_iov = iov; msg.msg_iovlen = 1; msg.msg_control = control_un.control; - msg.msg_controllen = sizeof control_un.control; + msg.msg_controllen = sizeof(control_un.control); msg.msg_flags = 0; - if (recvmsg_timeout(fd2, &msg, sizeof buf) < 0) - goto failed; + if (recv_message(fd2, &msg, sizeof(buf)) < 0) { + rv = -2; + break; + } if (msg.msg_flags & MSG_CTRUNC) { - logmsgx("control data was truncated, MSG_CTRUNC flag is on"); - goto next_error; + logmsgx("control data was truncated, MSG_CTRUNC flag " + "is on"); + goto next; } + dbgmsg(("#%u msg_controllen = %u", i, + (u_int)msg.msg_controllen)); + if (i != 0 && sock_type == SOCK_STREAM) { if (msg.msg_controllen != 0) { - logmsgx("second message has control data, this is wrong for stream sockets"); - goto next_error; + logmsgx("second message has control data, " + "this is wrong for stream sockets"); + goto next; } - dbgmsg(("#%u msg_controllen = %u", i, - (u_int)msg.msg_controllen)); continue; } if (msg.msg_controllen < sizeof(struct cmsghdr)) { - logmsgx("#%u msg_controllen %u < %lu (sizeof(struct cmsghdr))", - i, (u_int)msg.msg_controllen, (u_long)sizeof(struct cmsghdr)); - goto next_error; + logmsgx("#%u msg_controllen %u < %zu " + "(sizeof(struct cmsghdr))", i, + (u_int)msg.msg_controllen, sizeof(struct cmsghdr)); + goto next; } - if ((cmptr = CMSG_FIRSTHDR(&msg)) == NULL) { + cmptr = CMSG_FIRSTHDR(&msg); + if (cmptr == NULL) { logmsgx("CMSG_FIRSTHDR is NULL"); - goto next_error; + goto next; } - dbgmsg(("#%u msg_controllen = %u, cmsg_len = %u", i, - (u_int)msg.msg_controllen, (u_int)cmptr->cmsg_len)); + dbgmsg(("#%u cmsg_len = %u", i, (u_int)cmptr->cmsg_len)); if (cmptr->cmsg_level != SOL_SOCKET) { logmsgx("#%u cmsg_level %d != SOL_SOCKET", i, cmptr->cmsg_level); - goto next_error; + goto next; } if (cmptr->cmsg_type != SCM_CREDS) { logmsgx("#%u cmsg_type %d != SCM_CREDS", i, cmptr->cmsg_type); - goto next_error; + goto next; } if (cmptr->cmsg_len < CMSG_LEN(SOCKCREDSIZE(1))) { - logmsgx("#%u cmsg_len %u != %lu (CMSG_LEN(SOCKCREDSIZE(1)))", - i, (u_int)cmptr->cmsg_len, (u_long)CMSG_LEN(SOCKCREDSIZE(1))); - goto next_error; + logmsgx("#%u cmsg_len %u != %zu " + "(CMSG_LEN(SOCKCREDSIZE(1)))", i, + (u_int)cmptr->cmsg_len, CMSG_LEN(SOCKCREDSIZE(1))); + goto next; } - sockcred = (const struct sockcred *)CMSG_DATA(cmptr); + sockcred = (struct sockcred *)CMSG_DATA(cmptr); - error2 = 0; if (sockcred->sc_uid != my_uid) { - logmsgx("#%u sc_uid %lu != %lu (UID of current process)", - i, (u_long)sockcred->sc_uid, (u_long)my_uid); - error2 = 1; + logmsgx("#%u sc_uid %lu != %lu (UID of current " + "process)", i, (u_long)sockcred->sc_uid, + (u_long)my_uid); + goto next; } if (sockcred->sc_euid != my_euid) { - logmsgx("#%u sc_euid %lu != %lu (EUID of current process)", - i, (u_long)sockcred->sc_euid, (u_long)my_euid); - error2 = 1; + logmsgx("#%u sc_euid %lu != %lu (EUID of current " + "process)", i, (u_long)sockcred->sc_euid, + (u_long)my_euid); + goto next; } if (sockcred->sc_gid != my_gid) { - logmsgx("#%u sc_gid %lu != %lu (GID of current process)", - i, (u_long)sockcred->sc_gid, (u_long)my_gid); - error2 = 1; + logmsgx("#%u sc_gid %lu != %lu (GID of current " + "process)", i, (u_long)sockcred->sc_gid, + (u_long)my_gid); + goto next; } if (sockcred->sc_egid != my_egid) { - logmsgx("#%u sc_egid %lu != %lu (EGID of current process)", - i, (u_long)sockcred->sc_gid, (u_long)my_egid); - error2 = 1; + logmsgx("#%u sc_egid %lu != %lu (EGID of current " + "process)", i, (u_long)sockcred->sc_gid, + (u_long)my_egid); + goto next; } if (sockcred->sc_ngroups > NGROUPS_MAX) { logmsgx("#%u sc_ngroups %d > %u (NGROUPS_MAX)", i, sockcred->sc_ngroups, NGROUPS_MAX); - error2 = 1; - } else if (sockcred->sc_ngroups < 0) { - logmsgx("#%u sc_ngroups %d < 0", - i, sockcred->sc_ngroups); - error2 = 1; - } else { - dbgmsg(("#%u sc_ngroups = %d", i, sockcred->sc_ngroups)); - if (check_groups(sockcred->sc_groups, sockcred->sc_ngroups) < 0) { - logmsgx("#%u sc_groups has wrong GIDs", i); - error2 = 1; - } + goto next; + } + if (sockcred->sc_ngroups < 0) { + logmsgx("#%u sc_ngroups %d < 0", i, + sockcred->sc_ngroups); + goto next; } - if (error2) - goto next_error; - - if ((cmptr = CMSG_NXTHDR(&msg, cmptr)) != NULL) { - logmsgx("#%u control data has extra header, this is wrong", - i); - goto next_error; + dbgmsg(("#%u sc_ngroups = %d", i, sockcred->sc_ngroups)); + if (check_groups(sockcred->sc_groups, + sockcred->sc_ngroups) < 0) { + logmsgx("#%u sc_groups has wrong GIDs", i); + goto next; } + if (CMSG_NXTHDR(&msg, cmptr) != NULL) { + logmsgx("#%u control data has extra header, this is " + "wrong", i); + goto next; + } continue; -next_error: - error = -1; +next: + rv = -1; } - -done_close: - if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) { - logmsg("close"); - return (-2); - } - return (error); - -failed: +done: if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) - logmsg("close"); - return (-2); + if (close_socket((char *)NULL, fd2) < 0) + rv = -2; + return (rv); } static int -t_sockcred(int type) +t_sockcred(const int type) { - int error, fd, optval; + int fd, rv, optval; assert(type == 0 || type == 1); - if ((fd = create_server_socket()) < 0) + fd = create_server_socket(); + if (fd < 0) return (-2); - if (sock_type == SOCK_STREAM) - if (listen(fd, LISTENQ) < 0) { - logmsg("listen"); - goto failed; - } + rv = -2; if (type == 0) { optval = 1; - if (setsockopt(fd, 0, LOCAL_CREDS, &optval, sizeof optval) < 0) { + if (setsockopt(fd, 0, LOCAL_CREDS, &optval, + sizeof(optval)) < 0) { logmsg("setsockopt(LOCAL_CREDS) for %s socket", - sock_type == SOCK_STREAM ? "stream listening" : "datagram"); - if (errno == ENOPROTOOPT) { - error = -1; - goto done_close; - } - goto failed; + sock_type_str); + if (errno == ENOPROTOOPT) + rv = -1; + goto done; } } - if ((client_pid = fork()) == (pid_t)-1) { - logmsg("fork"); - goto failed; - } + if (fork_client() < 0) + goto done; if (client_pid == 0) { - myname = "CLIENT"; - if (close_socket((const char *)NULL, fd) < 0) + if (close_socket((char *)NULL, fd) < 0) _exit(1); t_sockcred_client(type); } - if ((error = t_sockcred_server(type, fd, 2)) == -2) { - (void)wait_client(); - goto failed; - } + rv = t_sockcred_server(type, fd, 2); if (wait_client() < 0) - goto failed; - -done_close: - if (close_socket(serv_sock_path, fd) < 0) { - logmsgx("close_socket failed"); - return (-2); - } - return (error); - -failed: + rv = -2; +done: if (close_socket(serv_sock_path, fd) < 0) - logmsgx("close_socket failed"); - return (-2); + rv = -2; + return (rv); } static int @@ -1368,59 +1366,39 @@ t_sockcred_dgram(void) static int t_cmsgcred_sockcred(void) { - int error, fd, optval; + int fd, rv, optval; - if ((fd = create_server_socket()) < 0) + fd = create_server_socket(); + if (fd < 0) return (-2); - if (sock_type == SOCK_STREAM) - if (listen(fd, LISTENQ) < 0) { - logmsg("listen"); - goto failed; - } + rv = -2; optval = 1; - if (setsockopt(fd, 0, LOCAL_CREDS, &optval, sizeof optval) < 0) { - logmsg("setsockopt(LOCAL_CREDS) for %s socket", - sock_type == SOCK_STREAM ? "stream listening" : "datagram"); - if (errno == ENOPROTOOPT) { - error = -1; - goto done_close; - } - goto failed; + if (setsockopt(fd, 0, LOCAL_CREDS, &optval, sizeof(optval)) < 0) { + logmsg("setsockopt(LOCAL_CREDS) for %s socket", sock_type_str); + if (errno == ENOPROTOOPT) + rv = -1; + goto done; } - if ((client_pid = fork()) == (pid_t)-1) { - logmsg("fork"); - goto failed; - } + if (fork_client() < 0) + goto done; if (client_pid == 0) { - myname = "CLIENT"; - if (close_socket((const char *)NULL, fd) < 0) + if (close_socket((char *)NULL, fd) < 0) _exit(1); t_cmsgcred_client(1); } - if ((error = t_sockcred_server(0, fd, 1)) == -2) { - (void)wait_client(); - goto failed; - } + rv = t_sockcred_server(0, fd, 1); if (wait_client() < 0) - goto failed; - -done_close: - if (close_socket(serv_sock_path, fd) < 0) { - logmsgx("close_socket failed"); - return (-2); - } - return (error); - -failed: + rv = -2; +done: if (close_socket(serv_sock_path, fd) < 0) - logmsgx("close_socket failed"); - return (-2); + rv = -2; + return (rv); } /* @@ -1437,13 +1415,16 @@ t_timestamp_client(void) struct msghdr msg; struct iovec iov[1]; struct cmsghdr *cmptr; - int fd; + int fd, rv; + + rv = EXIT_FAILURE; - if ((fd = create_unbound_socket()) < 0) + fd = create_client_socket(); + if (fd < 0) goto failed; if (connect_server(fd) < 0) - goto failed_close; + goto done; iov[0].iov_base = ipc_message; iov[0].iov_len = IPC_MESSAGE_SIZE; @@ -1454,7 +1435,7 @@ t_timestamp_client(void) msg.msg_iovlen = 1; msg.msg_control = control_un.control; msg.msg_controllen = no_control_data ? - sizeof(struct cmsghdr) :sizeof control_un.control; + sizeof(struct cmsghdr) : sizeof(control_un.control); msg.msg_flags = 0; cmptr = CMSG_FIRSTHDR(&msg); @@ -1466,19 +1447,15 @@ t_timestamp_client(void) dbgmsg(("msg_controllen = %u, cmsg_len = %u", (u_int)msg.msg_controllen, (u_int)cmptr->cmsg_len)); - if (sendmsg_timeout(fd, &msg, IPC_MESSAGE_SIZE) < 0) - goto failed_close; - - if (close_socket((const char *)NULL, fd) < 0) - goto failed; - - _exit(0); - -failed_close: - (void)close_socket((const char *)NULL, fd); + if (send_message(fd, &msg, IPC_MESSAGE_SIZE) < 0) + goto done; + rv = EXIT_SUCCESS; +done: + if (close_socket((char *)NULL, fd) < 0) + rv = EXIT_FAILURE; failed: - _exit(1); + _exit(rv); } /* @@ -1486,40 +1463,44 @@ failed: * type followed by struct timeval{} from client. */ static int -t_timestamp_server(int fd1) +t_timestamp_server(const int fd1) { union { struct cmsghdr cm; - char control[CMSG_SPACE(sizeof(struct timeval)) + EXTRA_CMSG_SPACE]; + char control[CMSG_SPACE(sizeof(struct timeval)) + + EXTRA_CMSG_SPACE]; } control_un; - char buf[IPC_MESSAGE_SIZE]; - int error, fd2; struct msghdr msg; struct iovec iov[1]; struct cmsghdr *cmptr; const struct timeval *timeval; + int fd2, rv; + char buf[IPC_MESSAGE_SIZE]; if (sock_type == SOCK_STREAM) { - if ((fd2 = accept_timeout(fd1)) < 0) + fd2 = accept_connection(fd1); + if (fd2 < 0) return (-2); } else fd2 = fd1; iov[0].iov_base = buf; - iov[0].iov_len = sizeof buf; + iov[0].iov_len = sizeof(buf); msg.msg_name = NULL; msg.msg_namelen = 0; msg.msg_iov = iov; msg.msg_iovlen = 1; msg.msg_control = control_un.control; - msg.msg_controllen = sizeof control_un.control;; + msg.msg_controllen = sizeof(control_un.control); msg.msg_flags = 0; - if (recvmsg_timeout(fd2, &msg, sizeof buf) < 0) - goto failed; + if (recv_message(fd2, &msg, sizeof(buf)) < 0) { + rv = -2; + goto done; + } - error = -1; + rv = -1; if (msg.msg_flags & MSG_CTRUNC) { logmsgx("control data was truncated, MSG_CTRUNC flag is on"); @@ -1527,12 +1508,13 @@ t_timestamp_server(int fd1) } if (msg.msg_controllen < sizeof(struct cmsghdr)) { - logmsgx("msg_controllen %u < %lu (sizeof(struct cmsghdr))", - (u_int)msg.msg_controllen, (u_long)sizeof(struct cmsghdr)); + logmsgx("msg_controllen %u < %zu (sizeof(struct cmsghdr))", + (u_int)msg.msg_controllen, sizeof(struct cmsghdr)); goto done; } - if ((cmptr = CMSG_FIRSTHDR(&msg)) == NULL) { + cmptr = CMSG_FIRSTHDR(&msg); + if (cmptr == NULL) { logmsgx("CMSG_FIRSTHDR is NULL"); goto done; } @@ -1551,80 +1533,195 @@ t_timestamp_server(int fd1) } if (cmptr->cmsg_len != CMSG_LEN(sizeof(struct timeval))) { - logmsgx("cmsg_len %u != %lu (CMSG_LEN(sizeof(struct timeval))", - (u_int)cmptr->cmsg_len, (u_long)CMSG_LEN(sizeof(struct timeval))); + logmsgx("cmsg_len %u != %zu (CMSG_LEN(sizeof(struct timeval))", + (u_int)cmptr->cmsg_len, CMSG_LEN(sizeof(struct timeval))); goto done; } - timeval = (const struct timeval *)CMSG_DATA(cmptr); + timeval = (struct timeval *)CMSG_DATA(cmptr); - dbgmsg(("timeval tv_sec %jd, tv_usec %jd", + dbgmsg(("timeval tv_sec %"PRIdMAX", tv_usec %"PRIdMAX, (intmax_t)timeval->tv_sec, (intmax_t)timeval->tv_usec)); - if ((cmptr = CMSG_NXTHDR(&msg, cmptr)) != NULL) { - logmsgx("control data has extra header"); + if (CMSG_NXTHDR(&msg, cmptr) != NULL) { + logmsgx("control data has extra header, this is wrong"); goto done; } - error = 0; - + rv = 0; done: if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) { - logmsg("close"); - return (-2); - } - return (error); - -failed: - if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) - logmsg("close"); - return (-2); + if (close_socket((char *)NULL, fd2) < 0) + rv = -2; + return (rv); } static int t_timestamp(void) { - int error, fd; + int fd, rv; - if ((fd = create_server_socket()) < 0) + fd = create_server_socket(); + if (fd < 0) return (-2); - if (sock_type == SOCK_STREAM) - if (listen(fd, LISTENQ) < 0) { - logmsg("listen"); - goto failed; - } + rv = -2; - if ((client_pid = fork()) == (pid_t)-1) { - logmsg("fork"); - goto failed; - } + if (fork_client() < 0) + goto done; if (client_pid == 0) { - myname = "CLIENT"; - if (close_socket((const char *)NULL, fd) < 0) + if (close_socket((char *)NULL, fd) < 0) _exit(1); t_timestamp_client(); } - if ((error = t_timestamp_server(fd)) == -2) { - (void)wait_client(); - goto failed; - } + rv = t_timestamp_server(fd); if (wait_client() < 0) + rv = -2; +done: + if (close_socket(serv_sock_path, fd) < 0) + rv = -2; + return (rv); +} + +/* + * Verify that xucred structure has correct credentials. + */ +static int +check_xucred(const struct xucred *xucred, const socklen_t len) +{ + if (len != sizeof(*xucred)) { + logmsgx("option value size %zu != %zu (sizeof(struct xucred))", + (size_t)len, sizeof(*xucred)); + return (-1); + } + if (xucred->cr_version != XUCRED_VERSION) { + logmsgx("cr_version %u != %d (XUCRED_VERSION)", + xucred->cr_version, XUCRED_VERSION); + return (-1); + } + if (xucred->cr_uid != my_euid) { + logmsgx("cr_uid %lu != %lu (EUID of current process)", + (u_long)xucred->cr_uid, (u_long)my_euid); + return (-1); + } + if (xucred->cr_ngroups == 0) { + logmsgx("cr_ngroups = 0, this is wrong"); + return (-1); + } + if (xucred->cr_ngroups > NGROUPS) { + logmsgx("cr_ngroups %hu > %d (NGROUPS)", + xucred->cr_ngroups, NGROUPS); + return (-1); + } + if (xucred->cr_groups[0] != my_egid) { + logmsgx("cr_groups[0] %lu != %lu (EGID of current process)", + (u_long)xucred->cr_groups[0], (u_long)my_egid); + return (-1); + } + if (check_groups(xucred->cr_groups + 1, xucred->cr_ngroups - 1) < 0) { + logmsgx("cr_groups has wrong GIDs"); + return (-1); + } + return (0); +} + +/* + * Connect to server and set LOCAL_PEERCRED socket option for connected + * socket. Verify that credentials of the peer are correct. + */ +static void +t_peercred_client(void) +{ + struct xucred xucred; + socklen_t len; + int fd, rv; + + rv = EXIT_FAILURE; + + fd = create_client_socket(); + if (fd < 0) goto failed; - if (close_socket(serv_sock_path, fd) < 0) { - logmsgx("close_socket failed"); - return (-2); + if (connect_server(fd) < 0) + goto done; + + len = sizeof(xucred); + if (getsockopt(fd, 0, LOCAL_PEERCRED, &xucred, &len) < 0) { + logmsg("getsockopt(LOCAL_PEERCRED)"); + goto done; } - return (error); + if (check_xucred(&xucred, len) < 0) + goto done; +done: + rv = close_socket((char *)NULL, fd) < 0 ? EXIT_FAILURE : EXIT_SUCCESS; failed: + _exit(rv); +} + +/* + * Accept connection from client and set LOCAL_PEERCRED socket option for + * connected socket. Verify that credentials of the peer are correct. + */ +static int +t_peercred_server(const int fd1) +{ + struct xucred xucred; + socklen_t len; + int fd2, rv; + + fd2 = accept_connection(fd1); + if (fd2 < 0) + return (-2); + + len = sizeof(xucred); + if (getsockopt(fd2, 0, LOCAL_PEERCRED, &xucred, &len) < 0) { + logmsg("getsockopt(LOCAL_PEERCRED)"); + rv = -2; + goto done; + } + + if (check_xucred(&xucred, len) < 0) { + rv = -1; + goto done; + } + + rv = 0; +done: + if (close_socket((char *)NULL, fd2) < 0) + rv = -2; + return (rv); +} + +static int +t_peercred(void) +{ + int fd, rv; + + fd = create_server_socket(); + if (fd < 0) + return (-2); + + rv = -2; + + if (fork_client() < 0) + goto done; + + if (client_pid == 0) { + if (close_socket((char *)NULL, fd) < 0) + _exit(1); + t_peercred_client(); + } + + rv = t_peercred_server(fd); + + if (wait_client() < 0) + rv = -2; +done: if (close_socket(serv_sock_path, fd) < 0) - logmsgx("close_socket failed"); - return (-2); + rv = -2; + return (rv); } diff -ruNp unix_cmsg.orig/unix_cmsg.t unix_cmsg/unix_cmsg.t --- unix_cmsg.orig/unix_cmsg.t 2006-05-29 21:40:55.000000000 +0300 +++ unix_cmsg/unix_cmsg.t 2009-10-14 02:56:49.000000000 +0300 @@ -23,14 +23,15 @@ run() done } -echo "1..15" +echo "1..16" for desc in \ "Sending, receiving cmsgcred" \ "Receiving sockcred (listening socket has LOCAL_CREDS) # TODO" \ "Receiving sockcred (accepted socket has LOCAL_CREDS) # TODO" \ "Sending cmsgcred, receiving sockcred # TODO" \ - "Sending, receiving timestamp" + "Sending, receiving timestamp" \ + "Check LOCAL_PEERCRED socket option" do n=`expr ${n} + 1` run ${n} stream "" ${n} "STREAM ${desc}" @@ -48,10 +49,10 @@ do run ${n} dgram "" ${i} "DGRAM ${desc}" done -run 10 stream -z 1 "STREAM Sending, receiving cmsgcred (no control data)" -run 11 stream -z 4 "STREAM Sending cmsgcred, receiving sockcred (no control data) # TODO" -run 12 stream -z 5 "STREAM Sending, receiving timestamp (no control data)" +run 11 stream -z 1 "STREAM Sending, receiving cmsgcred (no control data)" +run 12 stream -z 4 "STREAM Sending cmsgcred, receiving sockcred (no control data) # TODO" +run 13 stream -z 5 "STREAM Sending, receiving timestamp (no control data)" -run 13 dgram -z 1 "DGRAM Sending, receiving cmsgcred (no control data)" -run 14 dgram -z 3 "DGRAM Sending cmsgcred, receiving sockcred (no control data) # TODO" -run 15 dgram -z 4 "DGRAM Sending, receiving timestamp (no control data)" +run 14 dgram -z 1 "DGRAM Sending, receiving cmsgcred (no control data)" +run 15 dgram -z 3 "DGRAM Sending cmsgcred, receiving sockcred (no control data) # TODO" +run 16 dgram -z 4 "DGRAM Sending, receiving timestamp (no control data)" From burt at cs.miami.edu Wed Oct 14 14:40:05 2009 From: burt at cs.miami.edu (Burt Rosenberg) Date: Wed Oct 14 14:40:11 2009 Subject: kern/130628: [nfs] NFS / rpc.lockd deadlock on 7.1-R Message-ID: <200910141440.n9EEe4nn088580@freefall.freebsd.org> The following reply was made to PR kern/130628; it has been noted by GNATS. From: Burt Rosenberg To: bug-followup@freebsd.org, Joe Marcus Clarke Cc: Subject: Re: kern/130628: [nfs] NFS / rpc.lockd deadlock on 7.1-R Date: Wed, 14 Oct 2009 10:31:45 -0400 --000e0cd6c8b6adc3e40475e605f0 Content-Type: text/plain; charset=ISO-8859-1 The patch which helped, but did not entirely fix the lock is not in 7.2-p4, i386. Furthermore, we now have a deadlock on an NFS mount between a free bsd 7.2-p3 and a Linux 2.6.18-164.el5 SMP i686 athlon i386, in this situation there is a cisco ASA 5220 between linux and freebsd boxes, and we run tcp nfs. On Thu, Sep 3, 2009 at 2:40 PM, Burt Rosenberg wrote: > It seems that : > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/130628 > > appears in 7.2-R-p3; With this kernel, against Fedora 8 distros: > > Linux prism09.cs.miami.edu 2.6.26.8-57.fc8 #1 SMP Thu Dec 18 18:59:49 EST > 2008 x86_64 x86_64 x86_64 GNU/Linux > > which are using NFS (tcp) to mount homedirs form the freebsd server to the > fedora client, > server will become unresponsive from the network during graphical login of > a client. > > Applying the patch given in the article > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/130628 seems at present to > fix the problem. Under a 7.2-R-p3, we can manifest the problem in a few > minutes, and under said kernel with patches as described in the article, and > as provided by diffs against the current source, we have not yet seen the > problem. > > When the problem appears, the sever cannot be pinged, an other network > connections are halted. > > On the server, for instance, top shows: > > Proc, state, pri > -------------------- > pc.lockd *tcpin -68 > nfsd - 4 > rpcbind select 44 > ntpd select 44 > nfsd select 44 > ... etc... > > > Also, > > ./lockd restart > Stopping lockd. > Waiting for PIDS: 1114, 1114, 1114, 1114,.... > > kill -9 1114 also ineffective. > > So it seems to be something spinning in lockd. > > I think this is a serious issue and would like to see it resolved. Our > setup is available if you would like to send instrumented code. I attach > diffs. > > > > --000e0cd6c8b6adc3e40475e605f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The patch which helped, but did not entirely fix the lock is not in 7.2-p4,= i386.

Furthermore, we now have a deadlock on an NFS mount between a= free bsd 7.2-p3 and a Linux 2.6.18-164.el5 SMP i686 athlon i386,

in this situation there is a=A0 cisco ASA 5220 between linux and freebsd bo= xes, and we run tcp nfs.



On Thu, = Sep 3, 2009 at 2:40 PM, Burt Rosenberg <burt@cs.miami.edu> wrote:
It seems that :=A0
http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/130= 628

appears in 7.2-R-p3; With this kernel, against Fedora 8 distros:

Linux prism0= 9.cs.miami.edu 2.6.26.8-57.fc8 #1 SMP Thu Dec 18 18:59:49 EST 2008 x86_= 64 x86_64 x86_64 GNU/Linux

which are using NFS (tcp) to mount homedi= rs form the freebsd server to the fedora client,
server will become unresponsive from the network during graphical login of = a client.

Applying the patch given in the article http:/= /www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/130628 seems at present to = fix the problem. Under a 7.2-R-p3, we can manifest the problem in a few min= utes, and under said kernel with patches as described in the article, and a= s provided by diffs against the current source, we have not yet seen the pr= oblem.

When the problem appears, the sever cannot be pinged, an other network = connections are halted.

On the server, for instance, top shows:
=
Proc, state, pri
--------------------
pc.lockd=A0=A0 *tcpin=A0=A0 -68
nfsd=A0=A0=A0=A0=A0=A0= =A0=A0=A0 -=A0=A0=A0=A0=A0=A0 4
rpcbind=A0= =A0=A0=A0 select=A0=A0 44
ntpd=A0=A0=A0=A0=A0=A0= =A0 select=A0=A0 44
nfsd=A0=A0=A0=A0=A0=A0= =A0 select=A0=A0 44
... etc...

Also,

./lo= ckd restart
Stopping lockd.
Waiting for PIDS: 1114,= 1114, 1114, 1114,....

kill -9 1114 also ineffective.

So it seems to be something s= pinning in lockd.

I think this is a serious issue and would like to see it resolved. Our = setup is available if you would like to send instrumented code. I attach di= ffs.




--000e0cd6c8b6adc3e40475e605f0-- From bjmccann at gmail.com Wed Oct 14 18:59:57 2009 From: bjmccann at gmail.com (Brian McCann) Date: Wed Oct 14 19:00:05 2009 Subject: sys/dev/mii/brgphy.c patch Message-ID: <2b5f066d0910141127j29fd2753wb231dceb9f1c3409@mail.gmail.com> Hi all. I've had a problem using the bce driver on an IBM HS21 blade, using a Nortel L3-7 switch. This problem was documented quite a while ago according to http://www.freebsd.org/cgi/query-pr.cgi?pr=118238. I took the patch provided in there, and applied it to FreeBSD 7.1 and it worked great. I maxed out a 100Mbps LAN connection...so no bandwidth hit either. I know 8.0 is in the RC phase...is there any chance that this simple patch can be put into 8.0? If you have any questions on what I did or more details on my setup, please don't hesitate to ask! Thanks! --Brian -- _-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_ Brian McCann "I don't have to take this abuse from you -- I've got hundreds of people waiting to abuse me." -- Bill Murray, "Ghostbusters" From lstewart at freebsd.org Wed Oct 14 20:22:06 2009 From: lstewart at freebsd.org (Lawrence Stewart) Date: Wed Oct 14 20:22:16 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <200910092003.57367.bschmidt@techwires.net> References: <20091009170839.142800@gmx.net> <200910092003.57367.bschmidt@techwires.net> Message-ID: <4AD632D8.1070402@freebsd.org> Bernhard Schmidt wrote: > On Friday 09 October 2009 19:08:39 Lutz Bichler wrote: >> Hi, >> >> does anybody know what happened to the attempts to support Intel WiFi >> 5100/5300 interfaces in the iwn-driver? Are any patches available which >> could be used to start working on support for these interfaces? > > I'm curious too, as I'm playing with idea to start porting the latest changes > to if_iwn from OpenBSD. Already started with adding the 5000 series firmware to > iwnfw... > Most recent effort to port Intel 5100 support that I'm aware of was done by Daniel Roethlisberger (cc'd). He has the work kicking around in a private svn repo. No idea what state it's in though. Cheers, Lawrence From daniel at roe.ch Wed Oct 14 23:33:51 2009 From: daniel at roe.ch (Daniel Roethlisberger) Date: Wed Oct 14 23:33:58 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <4AD632D8.1070402@freebsd.org> References: <20091009170839.142800@gmx.net> <200910092003.57367.bschmidt@techwires.net> <4AD632D8.1070402@freebsd.org> Message-ID: <20091014233348.GA66756@calvin.ustdmz.roe.ch> Lawrence Stewart 2009-10-14: > Bernhard Schmidt wrote: > > On Friday 09 October 2009 19:08:39 Lutz Bichler wrote: > > > does anybody know what happened to the attempts to support > > > Intel WiFi 5100/5300 interfaces in the iwn-driver? Are any > > > patches available which could be used to start working on > > > support for these interfaces? > > > > I'm curious too, as I'm playing with idea to start porting > > the latest changes to if_iwn from OpenBSD. Already started > > with adding the 5000 series firmware to iwnfw... > > Most recent effort to port Intel 5100 support that I'm aware of > was done by Daniel Roethlisberger (cc'd). He has the work > kicking around in a private svn repo. No idea what state it's > in though. I haven't had a chance to work on this for some time. A bunch of other folks are interested and/or working on it. I've added two of the most recently active ones to the Cc: list. The code in my svn repo [1] is not up to date with all the 802.11 changes in -current. Status is still that scanning works, but associating (tx actually) fails with a firmware exception. Brandon has made some progress on why this is happening, but no real fix yet I think. [1] https://svn.roe.ch/iwn/trunk -- Daniel Roethlisberger http://daniel.roe.ch/ From linimon at FreeBSD.org Thu Oct 15 01:00:57 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Oct 15 01:01:08 2009 Subject: kern/139565: [ipfilter] ipfilter ioctl SIOCDELST broken Message-ID: <200910150100.n9F10vqk027647@freefall.freebsd.org> Old Synopsis: ipfilter ioctl SIOCDELST broken New Synopsis: [ipfilter] ipfilter ioctl SIOCDELST broken Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Oct 15 01:00:16 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=139565 From qing.li at bluecoat.com Thu Oct 15 01:13:45 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Thu Oct 15 01:13:57 2009 Subject: ARP Changes Message-ID: > > I know that arp has changed a lot in FreeBSD 8. I am wondering if one > change was by design? In older versions of FreeBSD, if you ping a host > that is on a local network but is down, after a few seconds ping displays: > ping: sendto: Host is down > ping: sendto: Host is down > This turned out to be a regression bug. A wrong variable is used and the incomplete entry was timing out too fast. So the ARP probe continues indefinitely ... > > Using arp to display the arp table shows: > > host.domain (x.x.x.x) at (incomplete) on em0 [ethernet] I wasn't returning incomplete entries, but now I am ... I have a patch for both issues, but I need to clean up the code because that wrong variable is used elsewhere in the same module. I should be able to commit a permanent fix by tomorrow. -- Qing From jamesbrandongooch at gmail.com Thu Oct 15 03:49:51 2009 From: jamesbrandongooch at gmail.com (Brandon Gooch) Date: Thu Oct 15 03:49:58 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <20091014233348.GA66756@calvin.ustdmz.roe.ch> References: <20091009170839.142800@gmx.net> <200910092003.57367.bschmidt@techwires.net> <4AD632D8.1070402@freebsd.org> <20091014233348.GA66756@calvin.ustdmz.roe.ch> Message-ID: <179b97fb0910142019u455995a4s2cdcf8ba744d98bf@mail.gmail.com> On Wed, Oct 14, 2009 at 11:33 PM, Daniel Roethlisberger wrote: > Lawrence Stewart 2009-10-14: >> Bernhard Schmidt wrote: >> > On Friday 09 October 2009 19:08:39 Lutz Bichler wrote: >> > > does anybody know what happened to the attempts to support >> > > Intel WiFi 5100/5300 interfaces in the iwn-driver? Are any >> > > patches available which could be used to start working on >> > > support for these interfaces? >> > >> > I'm curious too, as I'm playing with idea to start porting >> > the latest changes to if_iwn from OpenBSD. Already started >> > with adding the 5000 series firmware to iwnfw... >> >> Most recent effort to port Intel 5100 support that I'm aware of >> was done by Daniel Roethlisberger (cc'd). He has the work >> kicking around in a private svn repo. No idea what state it's >> in though. > > I haven't had a chance to work on this for some time. ?A bunch of > other folks are interested and/or working on it. ?I've added two > of the most recently active ones to the Cc: list. > > The code in my svn repo [1] is not up to date with all the 802.11 > changes in -current. ?Status is still that scanning works, but > associating (tx actually) fails with a firmware exception. > Brandon has made some progress on why this is happening, but no > real fix yet I think. > > [1] https://svn.roe.ch/iwn/trunk > > -- > Daniel Roethlisberger > http://daniel.roe.ch/ > Hi everyone. Yes, it's true that I've found SOMETHING, although I'm still investigating why that something is happening in the first place. I'm having to work on it in between "real life", so that means I need the working, current driver in tree most of the time. I have a 5300 in another computer I'm planning on hacking around on in the near future so I can have both a 4965 and 5000 series test environment. Right now, I'm reading through these: man -k ieee80211 ...and friends. I don't know much about the technology, so I decided to start over from the beginning, making this whole "iwn driver update" more of a "learn FreeBSD's IEEE802.11 layer" thing (a long-term project). So, yeah, I'll share more as I get it :) -Brandon From bschmidt at techwires.net Thu Oct 15 06:16:06 2009 From: bschmidt at techwires.net (Bernhard Schmidt) Date: Thu Oct 15 06:16:12 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <179b97fb0910142019u455995a4s2cdcf8ba744d98bf@mail.gmail.com> References: <20091009170839.142800@gmx.net> <20091014233348.GA66756@calvin.ustdmz.roe.ch> <179b97fb0910142019u455995a4s2cdcf8ba744d98bf@mail.gmail.com> Message-ID: <200910150815.58174.bschmidt@techwires.net> Hi, Just to let you know, I started working on that myself and was finally able to get a connection and make traffic yesterday :) I'm still having issues scanning 5Ghz channels though.. anyways, I'll post updates on sunday. -- Bernhard From qing.li at bluecoat.com Thu Oct 15 06:25:58 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Thu Oct 15 06:26:04 2009 Subject: ARP Changes References: Message-ID: I have committed the fix into the -current branch, svn r198111. Please give it a try and I plan to MFC the patch into 8.0 release branch in 3 days. Thank you for the report. -- Qing -----Original Message----- From: owner-freebsd-current@freebsd.org on behalf of Li, Qing Sent: Wed 10/14/2009 6:12 PM To: lab@gta.com; qingli@freebsd.org Cc: freebsd-net@freebsd.org; freebsd-current@freebsd.org Subject: Re: ARP Changes > > I know that arp has changed a lot in FreeBSD 8. I am wondering if one > change was by design? In older versions of FreeBSD, if you ping a host > that is on a local network but is down, after a few seconds ping displays: > ping: sendto: Host is down > ping: sendto: Host is down > This turned out to be a regression bug. A wrong variable is used and the incomplete entry was timing out too fast. So the ARP probe continues indefinitely ... > > Using arp to display the arp table shows: > > host.domain (x.x.x.x) at (incomplete) on em0 [ethernet] I wasn't returning incomplete entries, but now I am ... I have a patch for both issues, but I need to clean up the code because that wrong variable is used elsewhere in the same module. I should be able to commit a permanent fix by tomorrow. -- Qing _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From rihad at mail.ru Thu Oct 15 08:13:32 2009 From: rihad at mail.ru (rihad) Date: Thu Oct 15 08:13:39 2009 Subject: dummynet dropping too many packets Message-ID: <4AD6D99E.10805@mail.ru> For now we've mostly disabled dummynet and the drops have stopped, thanks to some extra unused bandwidth we have. But this isn't a real solution, of course, so this weekend I'm going to try the suggestion made by Robert Watson: > In the driver init code in if_bce, the following code appears: > > ifp->if_snd.ifq_drv_maxlen = USABLE_TX_BD; > IFQ_SET_MAXLEN(&ifp->if_snd, ifp->if_snd.ifq_drv_maxlen); > IFQ_SET_READY(&ifp->if_snd); > > Which evaluates to a architecture-specific value due to varying pagesize. You might just try forcing it to 1024. But I've looked in /sys/dev/bce/if_bcereg.h of our FreeBSD 7.1 source code and found this: #define TX_PAGES 2 #define TOTAL_TX_BD_PER_PAGE (BCM_PAGE_SIZE / sizeof(struct tx_bd)) #define USABLE_TX_BD_PER_PAGE (TOTAL_TX_BD_PER_PAGE - 1) #define TOTAL_TX_BD (TOTAL_TX_BD_PER_PAGE * TX_PAGES) #define USABLE_TX_BD (USABLE_TX_BD_PER_PAGE * TX_PAGES) #define MAX_TX_BD (TOTAL_TX_BD - 1) meaning that USABLE_TX_BD is expected to be smaller than MAX_TX_BD. What if MAX_TX_BD is itself way smaller than 1024, which I'll eventually set ifq_drv_maxlen to? Can a driver guru please comment on this? In a few days I'm going to try it anyway, and if the system locks up I'll just revert back to the original code, and order a darn expensive Intel 10 Gige card, but it won't hurt to ask beforehand. TIA From rwatson at FreeBSD.org Thu Oct 15 12:36:49 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Oct 15 12:37:22 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AD6D99E.10805@mail.ru> References: <4AD6D99E.10805@mail.ru> Message-ID: On Thu, 15 Oct 2009, rihad wrote: > meaning that USABLE_TX_BD is expected to be smaller than MAX_TX_BD. What if > MAX_TX_BD is itself way smaller than 1024, which I'll eventually set > ifq_drv_maxlen to? Can a driver guru please comment on this? In a few days > I'm going to try it anyway, and if the system locks up I'll just revert back > to the original code, and order a darn expensive Intel 10 Gige card, but it > won't hurt to ask beforehand. Depending on your tolerance for experimentalism, it might be useful to use DTrace to confirm our interpretation of events. The way I'd do this is to add an instrumentation point (using SDT) to the points where the statistics of interest are getting bumped, and then profile using DTrace for a bit with the following script: the:event:name:here { @data[stack()] = count(); } Let it run for 30-60 seconds, and you should get back a report on the frequency of each possible code path to generate the statistic. We believe that the drops are a result of bursts of packets from dummynet, in which case the dominant trace should be to dummynet timers. It would be interesting to see if that's right. If I get a chance, I'll spend a few minutes today looking at a more general patch to make it easy to use DTrace with network stack error points. Robert From rihad at mail.ru Thu Oct 15 16:15:39 2009 From: rihad at mail.ru (rihad) Date: Thu Oct 15 16:15:46 2009 Subject: dummynet dropping too many packets In-Reply-To: References: <4AD6D99E.10805@mail.ru> Message-ID: <4AD74AA8.1030203@mail.ru> Robert Watson wrote: > > On Thu, 15 Oct 2009, rihad wrote: > >> meaning that USABLE_TX_BD is expected to be smaller than MAX_TX_BD. >> What if MAX_TX_BD is itself way smaller than 1024, which I'll >> eventually set ifq_drv_maxlen to? Can a driver guru please comment on >> this? In a few days I'm going to try it anyway, and if the system >> locks up I'll just revert back to the original code, and order a darn >> expensive Intel 10 Gige card, but it won't hurt to ask beforehand. > > Depending on your tolerance for experimentalism, it might be useful to > use DTrace to confirm our interpretation of events. The way I'd do this > is to add an instrumentation point (using SDT) to the points where the > statistics of interest are getting bumped, and then profile using DTrace > for a bit with the following script: > > the:event:name:here > { > @data[stack()] = count(); > } > > Let it run for 30-60 seconds, and you should get back a report on the > frequency of each possible code path to generate the statistic. We > believe that the drops are a result of bursts of packets from dummynet, > in which case the dominant trace should be to dummynet timers. It would > be interesting to see if that's right. > Thanks, but as I haven't ever played with DTrace before, but for the sake of FreeBSD and for our own sake, could you or someone else provide me with a step-by-step tutorial on how to do exactly that? I hear GENERIC kernel lacks DTrace support, so I must rebuild it with KDTRACE_HOOKS enabled? Does such support hurt normal performance while dtrace is not being used? I'm a bit afraid of experimenting on a production box belonging to a business I do not own. Meanwhile today I've emailed David Christensen mentioned in the bce source code, asking him if it's ok to change that value. > If I get a chance, I'll spend a few minutes today looking at a more > general patch to make it easy to use DTrace with network stack error > points. > > Robert > > From jamesbrandongooch at gmail.com Fri Oct 16 00:52:27 2009 From: jamesbrandongooch at gmail.com (Brandon Gooch) Date: Fri Oct 16 00:52:35 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <200910150815.58174.bschmidt@techwires.net> References: <20091009170839.142800@gmx.net> <20091014233348.GA66756@calvin.ustdmz.roe.ch> <179b97fb0910142019u455995a4s2cdcf8ba744d98bf@mail.gmail.com> <200910150815.58174.bschmidt@techwires.net> Message-ID: <179b97fb0910151752o28cc87d4g5d9450b556b71307@mail.gmail.com> On Thu, Oct 15, 2009 at 6:15 AM, Bernhard Schmidt wrote: > Hi, > > Just to let you know, I started working on that myself and was finally able to > get a connection and make traffic yesterday :) I'm still having issues scanning > 5Ghz channels though.. anyways, I'll post updates on ?sunday. > > -- > Bernhard > That's great! BTW, which chip are you working with? Are you planning on pushing back your updates to Daniel's SVN repo? -Brandon From bschmidt at techwires.net Fri Oct 16 06:30:44 2009 From: bschmidt at techwires.net (Bernhard Schmidt) Date: Fri Oct 16 06:30:51 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <179b97fb0910151752o28cc87d4g5d9450b556b71307@mail.gmail.com> References: <20091009170839.142800@gmx.net> <200910150815.58174.bschmidt@techwires.net> <179b97fb0910151752o28cc87d4g5d9450b556b71307@mail.gmail.com> Message-ID: <200910160830.37821.bschmidt@techwires.net> On Friday 16 October 2009 02:52:26 Brandon Gooch wrote: > On Thu, Oct 15, 2009 at 6:15 AM, Bernhard Schmidt > > wrote: > > Hi, > > > > Just to let you know, I started working on that myself and was finally > > able to get a connection and make traffic yesterday :) I'm still having > > issues scanning 5Ghz channels though.. anyways, I'll post updates on > > sunday. > > > > -- > > Bernhard > > That's great! > > BTW, which chip are you working with? Are you planning on pushing back > your updates to Daniel's SVN repo? I'm working with a 5100 currently, I do also have a 5300 and 4965 to test. As I did start from scratch (didn't know about the repo at that point) the diff against that it is probably quite large, have to check that though. -- Bernhard From mgaron at pleora.com Fri Oct 16 21:07:26 2009 From: mgaron at pleora.com (Martin Garon) Date: Fri Oct 16 21:07:33 2009 Subject: Native support for AutoIP (aka LLA, RFC 3927). Message-ID: Hi, I need to implement AutoIP in my embedded FW that uses a snapshot of FreeBSD 4.4 network stack. I could not find any support for it in the latest development cvs tree. Any chance it is somewhere that I missed? If there is no support, anyone could suggest a good approach to this? I am thinking porting libpcap in order to access the data link layer to intercept/inject some ARP packets. All comments welcomed, Regards, --Martin mgaron AT pleora DOT com From rihad at mail.ru Sat Oct 17 05:22:31 2009 From: rihad at mail.ru (rihad) Date: Sat Oct 17 05:22:39 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AD6D99E.10805@mail.ru> References: <4AD6D99E.10805@mail.ru> Message-ID: <4AD95493.40200@mail.ru> rihad wrote: > For now we've mostly disabled dummynet and the drops have stopped, > thanks to some extra unused bandwidth we have. But this isn't a real > solution, of course, so this weekend I'm going to try the suggestion > made by Robert Watson: > > > In the driver init code in if_bce, the following code appears: > > > > ifp->if_snd.ifq_drv_maxlen = USABLE_TX_BD; > > IFQ_SET_MAXLEN(&ifp->if_snd, ifp->if_snd.ifq_drv_maxlen); > > IFQ_SET_READY(&ifp->if_snd); > > > > Which evaluates to a architecture-specific value due to varying > pagesize. You might just try forcing it to 1024. > In a few days I'm going to try it anyway, and if the system locks up > I'll just revert back to the original code > > TIA > Just rebooted with the "ifp->if_snd.ifq_drv_maxlen = 1024;" kernel, all ok so far. There's currenlty only 1000 or so entries in the ipfw table and around 350-400 net mbps load, so I'll wait a few hours for the numbers to grow to >2000 and 460-480 respectively and see if the drops still occur. P.S.: BTW, there's a small admin-type inconsistency in FreeBSD 7.1: /etc/rc.firewall gets executed before values set by /etc/sysctl.conf are in effect, so "queue 2000" isn't allowed in ipfw pipe rules (as net.inet.ip.dummynet.pipe_slot_limit is only 100 by default), so the rules are silently failing without any trace in the log files - I only saw the errors at the console. From rihad at mail.ru Sat Oct 17 05:28:09 2009 From: rihad at mail.ru (rihad) Date: Sat Oct 17 05:28:16 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AD95493.40200@mail.ru> References: <4AD6D99E.10805@mail.ru> <4AD95493.40200@mail.ru> Message-ID: <4AD955E7.2000501@mail.ru> rihad wrote: > so the rules are silently failing without any trace in the log files > - I only saw the errors at the console. > It turns out to be quite easy to fix the logging: from /etc/syslog.conf: # uncomment this to log all writes to /dev/console to /var/log/console.log #console.info /var/log/console.log but the sysctl->ipfw rc inconsistency there still is. From rihad at mail.ru Sat Oct 17 06:28:55 2009 From: rihad at mail.ru (rihad) Date: Sat Oct 17 06:29:02 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AD95493.40200@mail.ru> References: <4AD6D99E.10805@mail.ru> <4AD95493.40200@mail.ru> Message-ID: <4AD96422.1040008@mail.ru> rihad wrote: > rihad wrote: >> For now we've mostly disabled dummynet and the drops have stopped, >> thanks to some extra unused bandwidth we have. But this isn't a real >> solution, of course, so this weekend I'm going to try the suggestion >> made by Robert Watson: >> >> > In the driver init code in if_bce, the following code appears: >> > >> > ifp->if_snd.ifq_drv_maxlen = USABLE_TX_BD; >> > IFQ_SET_MAXLEN(&ifp->if_snd, ifp->if_snd.ifq_drv_maxlen); >> > IFQ_SET_READY(&ifp->if_snd); >> > >> > Which evaluates to a architecture-specific value due to varying >> pagesize. You might just try forcing it to 1024. > >> In a few days I'm going to try it anyway, and if the system locks up >> I'll just revert back to the original code > >> TIA >> > > Just rebooted with the "ifp->if_snd.ifq_drv_maxlen = 1024;" kernel, all > ok so far. There's currenlty only 1000 or so entries in the ipfw table > and around 350-400 net mbps load, so I'll wait a few hours for the > numbers to grow to >2000 and 460-480 respectively and see if the drops > still occur. > The change definitely helped! There are now more than 3200 users online, 460-500 mbps net traffic load, and normally 10-60 (up to 150 once or twice) consistent drops per second as opposed to several hundred up to 1000-1500 packets dropped per second before the rebuild. What's interesting is that the drops now began only after the ipfw table had around 3000 entries, not 2000 like before, so the change definitely helped. Just how high can maxlen be? Should I try 2048? 4096? From julian at elischer.org Sat Oct 17 08:14:46 2009 From: julian at elischer.org (Julian Elischer) Date: Sat Oct 17 08:14:53 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AD96422.1040008@mail.ru> References: <4AD6D99E.10805@mail.ru> <4AD95493.40200@mail.ru> <4AD96422.1040008@mail.ru> Message-ID: <4AD97CF7.6020602@elischer.org> rihad wrote: >> > The change definitely helped! There are now more than 3200 users online, > 460-500 mbps net traffic load, and normally 10-60 (up to 150 once or > twice) consistent drops per second as opposed to several hundred up to > 1000-1500 packets dropped per second before the rebuild. What's > interesting is that the drops now began only after the ipfw table had > around 3000 entries, not 2000 like before, so the change definitely > helped. Just how high can maxlen be? Should I try 2048? 4096? is Hz still 4000? From rwatson at FreeBSD.org Sat Oct 17 09:21:53 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat Oct 17 09:21:59 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AD95493.40200@mail.ru> References: <4AD6D99E.10805@mail.ru> <4AD95493.40200@mail.ru> Message-ID: On Sat, 17 Oct 2009, rihad wrote: > P.S.: BTW, there's a small admin-type inconsistency in FreeBSD 7.1: > /etc/rc.firewall gets executed before values set by /etc/sysctl.conf are in > effect, so "queue 2000" isn't allowed in ipfw pipe rules (as > net.inet.ip.dummynet.pipe_slot_limit is only 100 by default), so the rules > are silently failing without any trace in the log files - I only saw the > errors at the console. This is awkward to fix for sysctls, because the firewall module may not be loaded until the firewall stage of the boot process, so the sysctl wouldn't take effect (and perhaps this is what you're seeing, in fact?). Some sysctls have associated loader tunables, which you can set in /boot/loader.conf (and affect configuration when the module is loaded), but it looks like that isn't true for net.inet.ip.dummynet.pipe_slot_limit. Robert N M Watson Computer Laboratory University of Cambridge From rwatson at FreeBSD.org Sat Oct 17 09:24:10 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat Oct 17 09:24:16 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AD96422.1040008@mail.ru> References: <4AD6D99E.10805@mail.ru> <4AD95493.40200@mail.ru> <4AD96422.1040008@mail.ru> Message-ID: On Sat, 17 Oct 2009, rihad wrote: >> Just rebooted with the "ifp->if_snd.ifq_drv_maxlen = 1024;" kernel, all ok >> so far. There's currenlty only 1000 or so entries in the ipfw table and >> around 350-400 net mbps load, so I'll wait a few hours for the numbers to >> grow to >2000 and 460-480 respectively and see if the drops still occur. > > The change definitely helped! There are now more than 3200 users online, > 460-500 mbps net traffic load, and normally 10-60 (up to 150 once or twice) > consistent drops per second as opposed to several hundred up to 1000-1500 > packets dropped per second before the rebuild. What's interesting is that > the drops now began only after the ipfw table had around 3000 entries, not > 2000 like before, so the change definitely helped. Just how high can maxlen > be? Should I try 2048? 4096? Sure, those should both be safe to use in your configuration, although as the numbers get higher, potential kernel memory use increases, as does the risk of starvation for clusters. Keep an eye on "netstat -m" errors to see if you are reaching configured resouce limits (which you've probably increased already). Robert From oliver at akephalos.de Sat Oct 17 10:00:18 2009 From: oliver at akephalos.de (O.Herold) Date: Sat Oct 17 10:00:25 2009 Subject: kern/137776: [rum] panic in rum(4) driver on 8.0-BETA2 Message-ID: <200910171000.n9HA0HFB044281@freefall.freebsd.org> The following reply was made to PR kern/137776; it has been noted by GNATS. From: "O.Herold" To: bug-followup@freebsd.org, flz@freebsd.org Cc: Subject: Re: kern/137776: [rum] panic in rum(4) driver on 8.0-BETA2 Date: Sat, 17 Oct 2009 11:38:35 +0200 Hi, there is a fix for this kind of bug. I tried it myself (FreeBSD 8.0 RC1) and it works like a charm. I had a stable connection without any panic (the first one since using if_rum driver in FreeBSD; see the PRs) for several hours while downloading and installing different packages on a new system. http://lists.freebsd.org/pipermail/freebsd-current/2009-October/012659.html Would be nice to see this fix in stable, I think it's too late for the release. Cheers, Oliver Herold -- F!XMBR:http://www.fixmbr.de From rihad at mail.ru Sat Oct 17 13:49:12 2009 From: rihad at mail.ru (rihad) Date: Sat Oct 17 13:49:19 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AD97CF7.6020602@elischer.org> References: <4AD6D99E.10805@mail.ru> <4AD95493.40200@mail.ru> <4AD96422.1040008@mail.ru> <4AD97CF7.6020602@elischer.org> Message-ID: <4AD9CB54.2020608@mail.ru> Julian Elischer wrote: > rihad wrote: > >>> >> The change definitely helped! There are now more than 3200 users >> online, 460-500 mbps net traffic load, and normally 10-60 (up to 150 >> once or twice) consistent drops per second as opposed to several >> hundred up to 1000-1500 packets dropped per second before the rebuild. >> What's interesting is that the drops now began only after the ipfw >> table had around 3000 entries, not 2000 like before, so the change >> definitely helped. Just how high can maxlen be? Should I try 2048? 4096? > > is Hz still 4000? > No, I've set it to 2000 as per recommendations for HZ in NOTES. Should I try 4000? 6000? 8000? Or maybe just increase the bce queue length and rebuild? :) From rihad at mail.ru Sat Oct 17 14:02:16 2009 From: rihad at mail.ru (rihad) Date: Sat Oct 17 14:02:23 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AD95493.40200@mail.ru> References: <4AD6D99E.10805@mail.ru> <4AD95493.40200@mail.ru> Message-ID: <4AD9CE66.3010800@mail.ru> rihad wrote: > Just rebooted with the "ifp->if_snd.ifq_drv_maxlen = 1024;" kernel, all > ok so far. There's currenlty only 1000 or so entries in the ipfw table > and around 350-400 net mbps load, so I'll wait a few hours for the > numbers to grow to >2000 and 460-480 respectively and see if the drops > still occur. > I'm not sure of anything now... It's 7 p.m. here, and during this busy time of day in terms of network use there are 350-500 up to 600 drops per second at around 530-550 mbps net load. This is roughly equivalent to 2-7 mbps dropped on output. It might be better than before. Next thing I'll try is bce queue maxlen 1024 -> 2048, and HZ 2000 again "back" to 4000. From rihad at mail.ru Sat Oct 17 15:01:11 2009 From: rihad at mail.ru (rihad) Date: Sat Oct 17 15:01:18 2009 Subject: dummynet dropping too many packets In-Reply-To: References: <4AD6D99E.10805@mail.ru> <4AD95493.40200@mail.ru> Message-ID: <4AD9DC34.50600@mail.ru> Robert Watson wrote: > > On Sat, 17 Oct 2009, rihad wrote: > >> P.S.: BTW, there's a small admin-type inconsistency in FreeBSD 7.1: >> /etc/rc.firewall gets executed before values set by /etc/sysctl.conf >> are in effect, so "queue 2000" isn't allowed in ipfw pipe rules (as >> net.inet.ip.dummynet.pipe_slot_limit is only 100 by default), so the >> rules are silently failing without any trace in the log files - I only >> saw the errors at the console. > > This is awkward to fix for sysctls, because the firewall module may not > be loaded until the firewall stage of the boot process, so the sysctl > wouldn't take effect (and perhaps this is what you're seeing, in fact?). > Well, my kernel is built with IPFIREWALL enabled, so ipfw module is unneeded and doesn't get loaded automatically. I rather still think it's the order of execution that matters. For that matter I've worked around the problem for now by setting the sysctls explicitly in /etc/rc.firewall right before configuring the pipes: /sbin/sysctl net.inet.ip.dummynet.hash_size=512 /sbin/sysctl net.inet.ip.dummynet.pipe_slot_limit=2000 and commented them out in /etc/sysctl.conf with an XXX Now I see that this is also the reason why setting net.inet.ip.dummynet.hash_size in sysctl.conf had no effect on the hash table size at the time of creation of the pipes. > Some sysctls have associated loader tunables, which you can set in > /boot/loader.conf (and affect configuration when the module is loaded), > but it looks like that isn't true for net.inet.ip.dummynet.pipe_slot_limit. > > Robert N M Watson > Computer Laboratory > University of Cambridge > > From peterjeremy at acm.org Sat Oct 17 21:54:59 2009 From: peterjeremy at acm.org (Peter Jeremy) Date: Sat Oct 17 21:55:06 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AC8A76B.3050502@mail.ru> References: <4AC8A76B.3050502@mail.ru> Message-ID: <20091017215454.GG38569@server.vk2pj.dyndns.org> On 2009-Oct-04 18:47:23 +0500, rihad wrote: >Hi, we have around 500-600 mbit/s traffic flowing through a 7.1R Dell >PowerEdge w/ 2 GigE bce cards. There are currently around 4 thousand ISP >users online limited by dummynet pipes of various speeds. According to >netstat -s output around 500-1000 packets are being dropped every second >(this accounts for wasting around 7-12 mbit/s worth of traffic according >to systat -ifstat): This has been a most interesting thread. A couple of comments: Traffic shaping only works cleanly on TCP flows - UDP has no feedback mechanism and so will not automatically throttle to fit into the available bandwidth, potentially leading to high packet drops within dummynet. Is it possible that some of your customers are heavily using UDP? Have you tried allowing just UDP traffic to bypass the pipes to see if this has any effect on drop rate? The pipe lists you posted showed that virtually all the packet drops are associated with one or two IP addresses. If this is really true, rather than a measurement artifact, you might find it useful to tcpdump those addresses and see if there's anything unusual in the data being passed. Also, if you monitor the pipe lists following a cold start, do those addresses appear early and just not show any packet loss until the total number of users builds up or do they not appear until later and immediately show packet loss? Looking at how 'output packets dropped due to no bufs, etc.' is counted (ipstat.ips_odropped), if you run 'netstat -id', do you see a large number of drops on bce1 (consistent with the "output packets dropped" counts) or not? This will help narrow down the codepath being followed by dropped packets. Since the problem only appears to manifest when table(0) exceeds 2000 entries, have you considered splitting (at least temporarily) that table (and possibly table(2)) into two (eg table(0) and table(4))? This would help rule out an (unlikely) problem with table sizes. Doin so would require the application to split the users across both tables (eg round-robin or based on one of the bits in the IP address) and then duplicating the relevant ipfw rules - eg: 01060 pipe tablearg ip from any to table(0) out recv bce0 xmit bce1 01061 pipe tablearg ip from any to table(4) out recv bce0 xmit bce1 01070 allow ip from any to table(0) out recv bce0 xmit bce1 01071 allow ip from any to table(4) out recv bce0 xmit bce1 (And I agree that re-arranging rules to reduce the number of repeated tests should improve ipfw efficiency). The symptoms keep making me think "lock contention" - but I'm not sure how to measure that cheaply (AFAIK, LOCK_PROFILING is comparatively expensive). Finally, are you running i386 or amd64? -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20091017/7330f311/attachment.pgp From julian at elischer.org Sun Oct 18 01:20:26 2009 From: julian at elischer.org (Julian Elischer) Date: Sun Oct 18 01:20:33 2009 Subject: dummynet dropping too many packets In-Reply-To: <4AD9CB54.2020608@mail.ru> References: <4AD6D99E.10805@mail.ru> <4AD95493.40200@mail.ru> <4AD96422.1040008@mail.ru> <4AD97CF7.6020602@elischer.org> <4AD9CB54.2020608@mail.ru> Message-ID: <4ADA6D5B.9030601@elischer.org> rihad wrote: > Julian Elischer wrote: >> rihad wrote: >> >>>> >>> The change definitely helped! There are now more than 3200 users >>> online, 460-500 mbps net traffic load, and normally 10-60 (up to 150 >>> once or twice) consistent drops per second as opposed to several >>> hundred up to 1000-1500 packets dropped per second before the >>> rebuild. What's interesting is that the drops now began only after >>> the ipfw table had around 3000 entries, not 2000 like before, so the >>> change definitely helped. Just how high can maxlen be? Should I try >>> 2048? 4096? >> >> is Hz still 4000? >> > No, I've set it to 2000 as per recommendations for HZ in NOTES. Should I > try 4000? 6000? 8000? Or maybe just increase the bce queue length and > rebuild? :) you could try combinations. From dhorn2000 at gmail.com Sun Oct 18 04:03:48 2009 From: dhorn2000 at gmail.com (David Horn) Date: Sun Oct 18 04:03:54 2009 Subject: Native support for AutoIP (aka LLA, RFC 3927). In-Reply-To: References: Message-ID: <25ff90d60910172103y7b07b7e8wd7b8666bf2e9990b@mail.gmail.com> On Fri, Oct 16, 2009 at 4:38 PM, Martin Garon wrote: > Hi, > > > > I need to implement AutoIP in my embedded FW that uses a snapshot of FreeBSD > 4.4 network stack. > > > > I could not find any support for it in the latest development cvs tree. Any > chance it is somewhere that I missed? > > > > If there is no support, anyone could suggest a good approach to this? I am > thinking porting libpcap in order to access the data link layer to > intercept/inject some ARP packets. > > > > All comments welcomed, > Check out the Avahi implementation of IPv4 Link Local (RFC 3927). In ports under net/avahi-autoipd Good Luck -_Dave H From inpcb.harsha at gmail.com Sun Oct 18 06:28:38 2009 From: inpcb.harsha at gmail.com (Harsha) Date: Sun Oct 18 06:28:50 2009 Subject: Page fault in IFNET_WLOCK_ASSERT [if.c and pccbb.c] In-Reply-To: References: Message-ID: Hi Robert, Apologies for not getting earlier. On Mon, Oct 12, 2009 at 6:46 AM, Robert N. M. Watson wrote: > > Looks like a NULL pointer dereference, so perhaps a more traditional bug -- > could you convert ifindex_alloc_locked+0x71 to a line of code? You can do > this using kgdb on the kernel symbols file, perhaps "l > *ifindex_alloc_locked+0x71". It is the for loop in ifindex_alloc_locked() function- for (idx = 1; idx <= V_if_index; idx++) idx is a local variable, so I figured it is V_if_index is what is causing the page fault. It does look like a NULL pointer reference - I see that V_if_index comes from that vnet instance's value and uses the macro VNET_VNET_PTR() down the chain. Since the call chain is coming from a new thread cbb_event_thread, I believe that this thread's vnet context needs to be set using CURVNET_SET(). I'll try this tomorrow, but if think I'm not on the right track or want me to try something else please let me know. Many thanks, Harsha From rihad at mail.ru Sun Oct 18 06:30:41 2009 From: rihad at mail.ru (rihad) Date: Sun Oct 18 06:30:47 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091017215454.GG38569@server.vk2pj.dyndns.org> References: <4AC8A76B.3050502@mail.ru> <20091017215454.GG38569@server.vk2pj.dyndns.org> Message-ID: <4ADAB60E.8030309@mail.ru> Peter Jeremy wrote: > On 2009-Oct-04 18:47:23 +0500, rihad wrote: >> Hi, we have around 500-600 mbit/s traffic flowing through a 7.1R >> Dell PowerEdge w/ 2 GigE bce cards. There are currently around 4 >> thousand ISP users online limited by dummynet pipes of various >> speeds. According to netstat -s output around 500-1000 packets are >> being dropped every second (this accounts for wasting around 7-12 >> mbit/s worth of traffic according to systat -ifstat): > > This has been a most interesting thread. A couple of comments: > > Traffic shaping only works cleanly on TCP flows - UDP has no feedback > mechanism and so will not automatically throttle to fit into the > available bandwidth, potentially leading to high packet drops within > dummynet. Is it possible that some of your customers are heavily > using UDP? Have you tried allowing just UDP traffic to bypass the > pipes to see if this has any effect on drop rate? We only process inbound traffic, and anyway this problem couldn't be related because net.inet.ip.dummynet.io_pkt_drop normally doesn't reflect netstat -s's "output packets dropped" pace (e.g. now the former's only 1048, but the latter is as much as 1272587). > The pipe lists you posted showed that virtually all the packet drops > are associated with one or two IP addresses. If this is really true, Not really. There were only a few hundred of the several thousand online users in the list. Besides those drops are within sane limits (as determined by io_pkt_drop sysctl), it's the netstat -s's output packet drops that matter. > Also, if you monitor the pipe lists following a > cold start, do those addresses appear early and just not show any > packet loss until the total number of users builds up or do they not > appear until later and immediately show packet loss? > io_pkt_drop may rise at certain well-defined periods, like when turning dummynet on (by deleting the "allow ip from any to any" line before the pipes), and it may rise for certain heavy downloaders, but the value is normally negligible. > Looking at how 'output packets dropped due to no bufs, etc.' is > counted (ipstat.ips_odropped), if you run 'netstat -id', do you see a > large number of drops on bce1 (consistent with the "output packets > dropped" counts) or not? This will help narrow down the codepath > being followed by dropped packets. netstat -id: Yup, it's comparable: bce0 1500 00:1d:09:2a:06:7f 5518562854 0 14327023 0 0 0 bce1 1500 00:1d:09:xx:xx:xx 144918 0 5498628928 0 0 1135438 netstat -s: 1272587 output packets dropped due to no bufs, etc. > > Since the problem only appears to manifest when table(0) exceeds 2000 > entries, have you considered splitting (at least temporarily) that > table (and possibly table(2)) into two (eg table(0) and table(4))? > This would help rule out an (unlikely) problem with table sizes. Doin > so would require the application to split the users across both > tables (eg round-robin or based on one of the bits in the IP address) > and then duplicating the relevant ipfw rules - eg: > > 01060 pipe tablearg ip from any to table(0) out recv bce0 xmit bce1 > 01061 pipe tablearg ip from any to table(4) out recv bce0 xmit bce1 > 01070 allow ip from any to table(0) out recv bce0 xmit bce1 01071 > allow ip from any to table(4) out recv bce0 xmit bce1 > Around 3000 now (and around 480-500 mbps) as I've set the queue length in bce to 1024 and rebuilt the kernel. I'm going to increase that a bit again. I really think it's the dummynet burstiness, not table size per se, that results in the drops, and the value of burstiness depends on the number of "online" users. A command as simple as "ipfw table 0 flush" stops all drops instantly, but still allowing that traffic to pass through as is (thank God). It's quite easy for me to simulate the split in two by doing some shell scripting without touching any code, but I don't think it's the table sizes. I'll try that in case increasing the bce maxlen value won't help, though, so thank you. > (And I agree that re-arranging rules to reduce the number of repeated > tests should improve ipfw efficiency). > > The symptoms keep making me think "lock contention" - but I'm not > sure how to measure that cheaply (AFAIK, LOCK_PROFILING is > comparatively expensive). > > Finally, are you running i386 or amd64? > From julian at elischer.org Sun Oct 18 06:42:41 2009 From: julian at elischer.org (Julian Elischer) Date: Sun Oct 18 06:42:48 2009 Subject: Page fault in IFNET_WLOCK_ASSERT [if.c and pccbb.c] In-Reply-To: References: Message-ID: <4ADAB8E0.3090502@elischer.org> Harsha wrote: > Hi Robert, > > Apologies for not getting earlier. > > On Mon, Oct 12, 2009 at 6:46 AM, Robert N. M. Watson > wrote: >> Looks like a NULL pointer dereference, so perhaps a more traditional bug -- >> could you convert ifindex_alloc_locked+0x71 to a line of code? You can do >> this using kgdb on the kernel symbols file, perhaps "l >> *ifindex_alloc_locked+0x71". > It is the for loop in ifindex_alloc_locked() function- > for (idx = 1; idx <= V_if_index; idx++) > > idx is a local variable, so I figured it is V_if_index is what is > causing the page fault. It does look like a NULL pointer reference - I > see that V_if_index comes from that vnet instance's value and uses > the macro VNET_VNET_PTR() down the chain. Since the call chain is > coming from a new thread cbb_event_thread, I believe that this > thread's vnet context needs to be set using CURVNET_SET(). but only if you have options VIMAGE defined. if not then CURVNET_SET() is a NOP > > I'll try this tomorrow, but if think I'm not on the right track or > want me to try something else please let me know. > > Many thanks, > Harsha > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From rihad at mail.ru Sun Oct 18 08:11:24 2009 From: rihad at mail.ru (rihad) Date: Sun Oct 18 08:11:31 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091017215454.GG38569@server.vk2pj.dyndns.org> References: <4AC8A76B.3050502@mail.ru> <20091017215454.GG38569@server.vk2pj.dyndns.org> Message-ID: <4ADACDA8.2080506@mail.ru> Peter Jeremy wrote: > Since the problem only appears to manifest when table(0) exceeds 2000 > entries, have you considered splitting (at least temporarily) that > table (and possibly table(2)) into two (eg table(0) and table(4))? > This would help rule out an (unlikely) problem with table sizes. It was quite easy to simulate without touching any code: # ipfw table 0 list|wc -l 3697 # move half the table into the new table(1) # ipfw table 0 list|head -n1800|while read ip pipeid; do ipfw -q table 1 add $ip $pipeid && ipfw -q table 0 delete $ip; done # ipfw table 0 list|wc -l 1899 # ipfw table 1 list|wc -l 1800 # ipfw add 1061 pipe tablearg ip from any to table'(1)' out recv bce0 xmit bce1 now the ipfw looks like this: 01060 pipe tablearg ip from any to table(0) out recv bce0 xmit bce1 01061 pipe tablearg ip from any to table(1) out recv bce0 xmit bce1 The drops are at 100-200 per second. It may have descreased by 100-200 drops. Strangely, deleting rule 1061 instantly increases the drop rate to 300-400 up to 700/s, although there's still only 1980 entries in table(0), which is somewhat inexplicable. I'll increase the bce queue maxlen value one of these days and see. > > 01060 pipe tablearg ip from any to table(0) out recv bce0 xmit bce1 > 01061 pipe tablearg ip from any to table(4) out recv bce0 xmit bce1 > 01070 allow ip from any to table(0) out recv bce0 xmit bce1 > 01071 allow ip from any to table(4) out recv bce0 xmit bce1 > > (And I agree that re-arranging rules to reduce the number of repeated > tests should improve ipfw efficiency). > > The symptoms keep making me think "lock contention" - but I'm not sure > how to measure that cheaply (AFAIK, LOCK_PROFILING is comparatively > expensive). > > Finally, are you running i386 or amd64? > From rihad at mail.ru Sun Oct 18 08:39:10 2009 From: rihad at mail.ru (rihad) Date: Sun Oct 18 08:39:16 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ADACDA8.2080506@mail.ru> References: <4AC8A76B.3050502@mail.ru> <20091017215454.GG38569@server.vk2pj.dyndns.org> <4ADACDA8.2080506@mail.ru> Message-ID: <4ADAD42B.2070406@mail.ru> rihad wrote: > Peter Jeremy wrote: > >> Since the problem only appears to manifest when table(0) exceeds 2000 >> entries, have you considered splitting (at least temporarily) that >> table (and possibly table(2)) into two (eg table(0) and table(4))? >> This would help rule out an (unlikely) problem with table sizes. > It was quite easy to simulate without touching any code: > # ipfw table 0 list|wc -l > 3697 > # move half the table into the new table(1) > # ipfw table 0 list|head -n1800|while read ip pipeid; do ipfw -q table 1 > add $ip $pipeid && ipfw -q table 0 delete $ip; done > # ipfw table 0 list|wc -l > 1899 > # ipfw table 1 list|wc -l > 1800 > # ipfw add 1061 pipe tablearg ip from any to table'(1)' out recv bce0 > xmit bce1 > > now the ipfw looks like this: > 01060 pipe tablearg ip from any to table(0) out recv bce0 xmit bce1 > 01061 pipe tablearg ip from any to table(1) out recv bce0 xmit bce1 > > The drops are at 100-200 per second. It may have descreased by 100-200 > drops. Strangely, deleting rule 1061 instantly increases the drop rate > to 300-400 up to 700/s, although there's still only 1980 entries in > table(0), which is somewhat inexplicable. > Splitting the table 0 across 4 tables in the same way, resulting in each having around 500-600 entries didn't help much either: 01060 pipe tablearg ip from any to table(0) out recv bce0 xmit bce1 01061 pipe tablearg ip from any to table(10) out recv bce0 xmit bce1 01061 pipe tablearg ip from any to table(11) out recv bce0 xmit bce1 01061 pipe tablearg ip from any to table(12) out recv bce0 xmit bce1 Still 100-200-300-400 drops/s. From rihad at mail.ru Sun Oct 18 09:07:58 2009 From: rihad at mail.ru (rihad) Date: Sun Oct 18 09:08:08 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ADAD42B.2070406@mail.ru> References: <4AC8A76B.3050502@mail.ru> <20091017215454.GG38569@server.vk2pj.dyndns.org> <4ADACDA8.2080506@mail.ru> <4ADAD42B.2070406@mail.ru> Message-ID: <4ADADAEA.5050000@mail.ru> rihad wrote: > rihad wrote: >> Peter Jeremy wrote: >> >>> Since the problem only appears to manifest when table(0) exceeds 2000 >>> entries, have you considered splitting (at least temporarily) that >>> table (and possibly table(2)) into two (eg table(0) and table(4))? >>> This would help rule out an (unlikely) problem with table sizes. >> It was quite easy to simulate without touching any code: >> # ipfw table 0 list|wc -l >> 3697 >> # move half the table into the new table(1) >> # ipfw table 0 list|head -n1800|while read ip pipeid; do ipfw -q table >> 1 add $ip $pipeid && ipfw -q table 0 delete $ip; done >> # ipfw table 0 list|wc -l >> 1899 >> # ipfw table 1 list|wc -l >> 1800 >> # ipfw add 1061 pipe tablearg ip from any to table'(1)' out recv bce0 >> xmit bce1 >> >> now the ipfw looks like this: >> 01060 pipe tablearg ip from any to table(0) out recv bce0 xmit bce1 >> 01061 pipe tablearg ip from any to table(1) out recv bce0 xmit bce1 >> >> The drops are at 100-200 per second. It may have descreased by 100-200 >> drops. Strangely, deleting rule 1061 instantly increases the drop >> rate to 300-400 up to 700/s, although there's still only 1980 entries >> in table(0), which is somewhat inexplicable. >> > Splitting the table 0 across 4 tables in the same way, resulting in each > having around 500-600 entries didn't help much either: > 01060 pipe tablearg ip from any to table(0) out recv bce0 xmit bce1 > 01061 pipe tablearg ip from any to table(10) out recv bce0 xmit bce1 > 01061 pipe tablearg ip from any to table(11) out recv bce0 xmit bce1 > 01061 pipe tablearg ip from any to table(12) out recv bce0 xmit bce1 > > > Still 100-200-300-400 drops/s. > That's because I had neglected to also split the cross-ISP table 2, which for various reasons currently has less than 1% of total traffic. Despite that, and to my great surprise, flushing table 0 didn't stop the drops until I had also flushed the mostly idle table 2! I've just split both table(0) and table(2) in two, and the output drops were brought down to 20-80 up to 150 (in systat -ip). Now there are around 1700 in each of the tables 0 and 2, and exactly 1500 enries in each of the tables 10 and 20. 01060 pipe tablearg ip from any to table(0) out recv bce0 xmit bce1 01061 pipe tablearg ip from any to table(10) out recv bce0 xmit bce1 01070 allow ip from any to table(0) out recv bce0 xmit bce1 01071 allow ip from any to table(10) out recv bce0 xmit bce1 01100 pipe tablearg ip from any to table(2) 01101 pipe tablearg ip from any to table(20) From rihad at mail.ru Sun Oct 18 09:12:45 2009 From: rihad at mail.ru (rihad) Date: Sun Oct 18 09:12:50 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ADADAEA.5050000@mail.ru> References: <4AC8A76B.3050502@mail.ru> <20091017215454.GG38569@server.vk2pj.dyndns.org> <4ADACDA8.2080506@mail.ru> <4ADAD42B.2070406@mail.ru> <4ADADAEA.5050000@mail.ru> Message-ID: <4ADADC0B.5070706@mail.ru> rihad wrote: > I've just split both table(0) and table(2) in two, and the output drops > were brought down to 20-80 up to 150 (in systat -ip). Now there are > around 1700 in each of the tables 0 and 2, and exactly 1500 enries in > each of the tables 10 and 20. > > 01060 pipe tablearg ip from any to table(0) out recv bce0 xmit bce1 > 01061 pipe tablearg ip from any to table(10) out recv bce0 xmit bce1 > 01070 allow ip from any to table(0) out recv bce0 xmit bce1 > 01071 allow ip from any to table(10) out recv bce0 xmit bce1 > 01100 pipe tablearg ip from any to table(2) > 01101 pipe tablearg ip from any to table(20) > > I've just deleted rules 1061 1071 and 1101 and the drop rate went down to 0 with about 1700 entries in each of table 0 and table 2. So the size of one particular table doesn't matter much. From bschmidt at techwires.net Sun Oct 18 14:27:45 2009 From: bschmidt at techwires.net (Bernhard Schmidt) Date: Sun Oct 18 14:27:51 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <200910150815.58174.bschmidt@techwires.net> References: <20091009170839.142800@gmx.net> <179b97fb0910142019u455995a4s2cdcf8ba744d98bf@mail.gmail.com> <200910150815.58174.bschmidt@techwires.net> Message-ID: <200910181627.38060.bschmidt@techwires.net> On Thursday 15 October 2009 08:15:57 Bernhard Schmidt wrote: > .. anyways, I'll post updates on sunday. Here we go. http://techwires.net/~bschmidt/patches/freebsd/iwn/ Testers/feedback welcome! Code is pretty stable although there are still a few open issues. Nothing major I should be able to figure them out. * I did only tests with a 5100 card, other might not yet work.. I will do tests wie 5300 and 4965 cards later this week. * 11N has not been tested at all. * Deauth/disconnect frames are not handled correctly, those yield firmware errors. The remote side might therefore not be able to clean up correctly, whichs lead to no answers to probe requests on new scans. * Encryption of any kind does not yet work. * Monitor mode/radiotap does not yet work. * IBSS mode has not been tested. * iwnfw module is locked somehow on kldunload. * RF kill switch might not work correctly. * Manpage needs an update. :) * Suspend/resume is broken. -- Bernhard From pawel.worach at gmail.com Sun Oct 18 16:47:06 2009 From: pawel.worach at gmail.com (Pawel Worach) Date: Sun Oct 18 16:47:12 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <200910181627.38060.bschmidt@techwires.net> References: <20091009170839.142800@gmx.net> <179b97fb0910142019u455995a4s2cdcf8ba744d98bf@mail.gmail.com> <200910150815.58174.bschmidt@techwires.net> <200910181627.38060.bschmidt@techwires.net> Message-ID: <424927D3-F758-4C5D-BD29-D06781C5F9B1@gmail.com> On Oct 18, 2009, at 16:27, Bernhard Schmidt wrote: > > On Thursday 15 October 2009 08:15:57 Bernhard Schmidt wrote: >> .. anyways, I'll post updates on sunday. > > Here we go. > > http://techwires.net/~bschmidt/patches/freebsd/iwn/ > > Testers/feedback welcome! > > Code is pretty stable although there are still a few open issues. > Nothing > major I should be able to figure them out. > > * I did only tests with a 5100 card, other might not yet work.. I > will do > tests wie 5300 and 4965 cards later this week. > * 11N has not been tested at all. > * Deauth/disconnect frames are not handled correctly, those yield > firmware > errors. The remote side might therefore not be able to clean up > correctly, > whichs lead to no answers to probe requests on new scans. > * Encryption of any kind does not yet work. > * Monitor mode/radiotap does not yet work. > * IBSS mode has not been tested. > * iwnfw module is locked somehow on kldunload. > * RF kill switch might not work correctly. > * Manpage needs an update. :) > * Suspend/resume is broken. > Works here for an open network (FreeBSD 8.0-RC1), thanks for working on this! iwn0: mem 0xf4300000-0xf4301fff irq 17 at device 0.0 on pci3 iwn0: MIMO 3T3R, MoW, address 00:16:ea:e3:e2:82 iwn0: [ITHREAD] iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11na MCS: 15Mbps 30Mbps 45Mbps 60Mbps 90Mbps 120Mbps 135Mbps 150Mbps 30Mbps 60Mbps 90Mbps 120Mbps 180Mbps 240Mbps 270Mbps 300Mbps iwn0: 11ng MCS: 15Mbps 30Mbps 45Mbps 60Mbps 90Mbps 120Mbps 135Mbps 150Mbps 30Mbps 60Mbps 90Mbps 120Mbps 180Mbps 240Mbps 270Mbps 300Mbps wlan0: Ethernet address: 00:16:ea:e3:e2:82 wlan0: link state changed to UP iwn0: need multicast update callback iwn0: need multicast update callback iwn0: need multicast update callback wlan0: flags=8843 metric 0 mtu 1500 ether 00:16:ea:e3:e2:82 inet 10.0.1.17 netmask 0xffffff00 broadcast 10.0.1.255 media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g status: associated ssid "xxx" channel 11 (2462 Mhz 11g) bssid 00:xx:xx:xx:xx:xx country US authmode OPEN privacy OFF txpower 15 bmiss 10 scanvalid 60 protmode CTS wme roaming MANUAL -- Pawel > -- > Bernhard > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From lwindschuh at googlemail.com Sun Oct 18 20:03:23 2009 From: lwindschuh at googlemail.com (Lucius Windschuh) Date: Sun Oct 18 20:03:29 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <200910181627.38060.bschmidt@techwires.net> References: <20091009170839.142800@gmx.net> <179b97fb0910142019u455995a4s2cdcf8ba744d98bf@mail.gmail.com> <200910150815.58174.bschmidt@techwires.net> <200910181627.38060.bschmidt@techwires.net> Message-ID: <90a5caac0910181241p61850f84l999f18523e30fc01@mail.gmail.com> Hi Bernhard, I tried your module on my T400 with a PRO/Wireless 5300 and WITNESS, INVARIANTS enabled. If the RF kill switch is set to "WLAN disabled", this command sequence produces a panic: $ kldload iwnfw $ kldload if_iwn $ ifconfig wlan create wlandev iwn0 wlan0 $ ifconfig wlan0 up iwn0: iwn_init_locked: radio is disabled by hardware switch panic: _mtx_lock_sleep: recursed on non-recursive mutex iwn0 @ /usr/src/sys/modules/iwn/../../dev/iwn/if_iwn.c:5497 Locks: exclusive sleep mutex iwn0 (network driver) r = 0 (0xc8242008) locked @ /usr/src/sys/modules/iwn/../../dev/iwn/if_iwn.c:3091 exclusive sleep mutex iwn0 (network driver) r = 0 (0xc8242008) locked @ /usr/src/sys/modules/iwn/../../dev/iwn/if_iwn.c:3091 exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xc7f836fc) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xc7f833c4) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xc7f83560) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xc7f37d6c) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xc7f66898) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 exclusive lockmgr bufwait (bufwait) r = 0 (0xdae5ce20) locked @ /usr/src/sys/kern/vfs_bio.c:1835 exclusive lockmgr snaplk (snaplk) r = 0 (0xc7df01dc) locked @ /usr/src/sys/kern/vfs_vnops.c:536 db:0:kdb.enter.default> bt Tracing pid 2552 tid 100211 td 0xc7d2b230 kdb_enter(c09e4c81,c09e4c81,c09e365d,eb2b8ab0,1,...) at kdb_enter+0x3a panic(c09e365d,c7e97960,c823f4b4,1579,c8242008,...) at panic+0x136 _mtx_lock_sleep(c8242008,c7d2b230,0,c823f4b4,1579,...) at _mtx_lock_sleep+0x4a _mtx_lock_flags(c8242008,0,c823f4b4,1579,c6958800,...) at _mtx_lock_flags+0xf7 iwn_stop(c8242000,0,c823f4b4,c13,c828f000,...) at iwn_stop+0x32 iwn_ioctl(c6958800,80206910,c8291420,c7d2b230,eb2b8bac,...) at iwn_ioctl+0x102 ifioctl(c80a380c,80206910,c8291420,c7d2b230,c807e500,...) at ifioctl+0xa05 soo_ioctl(c8070dc8,80206910,c8291420,c6b71e00,c7d2b230,...) at soo_ioctl+0x415 kern_ioctl(c7d2b230,3,80206910,c8291420,6f5d10,...) at kern_ioctl+0x1dd ioctl(c7d2b230,eb2b8cf8,c,c09fbc00,c0a53bc8,...) at ioctl+0x134 syscall(eb2b8d38) at syscall+0x283 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281c8a13, esp = 0xbfbfe46c, ebp = 0xbfbfe4c8 --- BTW: With the RF kill switch set to "WLAN enabled", it works for open networks. But ifconfig wlan1 list ap did not return my 802.11a access point. Is this expected? Regards and thanks for the work. Lucius From bschmidt at techwires.net Sun Oct 18 20:37:02 2009 From: bschmidt at techwires.net (Bernhard Schmidt) Date: Sun Oct 18 20:37:08 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <90a5caac0910181241p61850f84l999f18523e30fc01@mail.gmail.com> References: <20091009170839.142800@gmx.net> <200910181627.38060.bschmidt@techwires.net> <90a5caac0910181241p61850f84l999f18523e30fc01@mail.gmail.com> Message-ID: <200910182236.55615.bschmidt@techwires.net> On Sunday 18 October 2009 21:41:36 Lucius Windschuh wrote: > Hi Bernhard, > I tried your module on my T400 with a PRO/Wireless 5300 and WITNESS, > INVARIANTS enabled. > If the RF kill switch is set to "WLAN disabled", this command sequence [..] Thanks for reporting this, there seems to be an issue in iwn_cleanup(). > BTW: With the RF kill switch set to "WLAN enabled", it works for open > networks. But ifconfig wlan1 list ap did not return my 802.11a access > point. Is this expected? No it's not. I'll noticed that also during the last tests, scanning on 5Ghz channels does not work reliably, setting a fixed channel works though. -- Bernhard From vassilis.laganakos at yahoo.com Sun Oct 18 22:50:03 2009 From: vassilis.laganakos at yahoo.com (Vassilis Laganakos) Date: Sun Oct 18 22:50:10 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <200910181627.38060.bschmidt@techwires.net> References: <20091009170839.142800@gmx.net> <179b97fb0910142019u455995a4s2cdcf8ba744d98bf@mail.gmail.com> <200910150815.58174.bschmidt@techwires.net> <200910181627.38060.bschmidt@techwires.net> Message-ID: <464343.38391.qm@web59410.mail.ac4.yahoo.com> Hello, > On Thursday 15 October 2009 08:15:57 Bernhard Schmidt wrote: > > .. anyways, I'll post updates on sunday. > > Here we go. > > http://techwires.net/~bschmidt/patches/freebsd/iwn/ > > Testers/feedback welcome! > > Code is pretty stable although there are still a few open issues. Nothing > major I should be able to figure them out. > > * I did only tests with a 5100 card, other might not yet work.. I will do > tests wie 5300 and 4965 cards later this week. > * 11N has not been tested at all. > * Deauth/disconnect frames are not handled correctly, those yield firmware > errors. The remote side might therefore not be able to clean up correctly, > whichs lead to no answers to probe requests on new scans. > * Encryption of any kind does not yet work. > * Monitor mode/radiotap does not yet work. > * IBSS mode has not been tested. > * iwnfw module is locked somehow on kldunload. > * RF kill switch might not work correctly. > * Manpage needs an update. :) > * Suspend/resume is broken. > Awesome! I was checking things out for iwn 5100, but I was getting firmware problems. I'll try your stuff on 8-STABLE and get back with info. Thank you very much for working on this! Best regards, Vassilis L. From inpcb.harsha at gmail.com Sun Oct 18 23:26:52 2009 From: inpcb.harsha at gmail.com (Harsha) Date: Sun Oct 18 23:27:20 2009 Subject: Page fault in IFNET_WLOCK_ASSERT [if.c and pccbb.c] In-Reply-To: <4ADAB8E0.3090502@elischer.org> References: <4ADAB8E0.3090502@elischer.org> Message-ID: On Sat, Oct 17, 2009 at 11:42 PM, Julian Elischer wrote: > Harsha wrote: >> wrote: >>> >>> Looks like a NULL pointer dereference, so perhaps a more traditional bug >>> -- >>> could you convert ifindex_alloc_locked+0x71 to a line of code? You can do >>> this using kgdb on the kernel symbols file, perhaps "l >>> *ifindex_alloc_locked+0x71". >> >> It is the for loop in ifindex_alloc_locked() function- >> ?for (idx = 1; idx <= V_if_index; idx++) >> >> idx is a local variable, so I figured it is V_if_index is what is >> causing the page fault. It does look like a NULL pointer reference - I >> see that V_if_index comes from that ?vnet instance's value and uses >> the macro VNET_VNET_PTR() down the chain. Since the call chain is >> coming from a new thread cbb_event_thread, I believe that this >> thread's vnet context needs to be set using CURVNET_SET(). > > but only if you have options VIMAGE defined. if not then CURVNET_SET() > is a NOP I do have the VIMAGE options turned on. Can someone tell me what is the right way to add the vnet context to cbb_event_thread? I tried adding context in two locations- 1. In cbb_insert() as- CURVNET_SET(TD_TO_VNET(curthread)); 2. In if_alloc() as- CURVNET_SET(TD_TO_VNET(curthread)); or as ifp = malloc(sizeof(struct ifnet), M_IFNET, M_WAITOK|M_ZERO); #ifdef VIMAGE ifp->if_vnet = curvnet; if (ifp->if_home_vnet == NULL) ifp->if_home_vnet = curvnet; CURVNET_SET(ifp->if_vnet); #endif But in all the cases I get a warning/error about unused variable 'saved_vnet' like this- cc1: warnings being treated as errors /usr/src/sys/net/if.c: In function 'if_alloc': /usr/src/sys/net/if.c:418: warning: unused variable 'saved_vnet' The backtrace is in the link I posted earlier. Thanks, Harsha From wen at FreeBSD.org Mon Oct 19 00:23:38 2009 From: wen at FreeBSD.org (wen@FreeBSD.org) Date: Mon Oct 19 00:23:44 2009 Subject: kern/138739: [wpi] wpi(4) does not work very well under 8.0-BETA4 Message-ID: <200910190023.n9J0NbO9075176@freefall.freebsd.org> Synopsis: [wpi] wpi(4) does not work very well under 8.0-BETA4 Responsible-Changed-From-To: freebsd-net->wen Responsible-Changed-By: wen Responsible-Changed-When: Mon Oct 19 00:23:37 UTC 2009 Responsible-Changed-Why: I'll take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=138739 From wen at FreeBSD.org Mon Oct 19 00:53:25 2009 From: wen at FreeBSD.org (wen@FreeBSD.org) Date: Mon Oct 19 00:53:32 2009 Subject: kern/138739: [wpi] wpi(4) does not work very well under 8.0-BETA4 Message-ID: <200910190053.n9J0rPir001981@freefall.freebsd.org> Synopsis: [wpi] wpi(4) does not work very well under 8.0-BETA4 Responsible-Changed-From-To: wen->freebsd-net Responsible-Changed-By: wen Responsible-Changed-When: Mon Oct 19 00:53:24 UTC 2009 Responsible-Changed-Why: Sorry I mistake it. http://www.freebsd.org/cgi/query-pr.cgi?pr=138739 From jamesbrandongooch at gmail.com Mon Oct 19 01:07:24 2009 From: jamesbrandongooch at gmail.com (Brandon Gooch) Date: Mon Oct 19 01:07:31 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <200910181627.38060.bschmidt@techwires.net> References: <20091009170839.142800@gmx.net> <179b97fb0910142019u455995a4s2cdcf8ba744d98bf@mail.gmail.com> <200910150815.58174.bschmidt@techwires.net> <200910181627.38060.bschmidt@techwires.net> Message-ID: <179b97fb0910181807t6576fcceh7b5850911199c558@mail.gmail.com> On Sun, Oct 18, 2009 at 2:27 PM, Bernhard Schmidt wrote: > On Thursday 15 October 2009 08:15:57 Bernhard Schmidt wrote: >> .. anyways, I'll post updates on ?sunday. > > Here we go. > > http://techwires.net/~bschmidt/patches/freebsd/iwn/ > > Testers/feedback welcome! > > Code is pretty stable although there are still a few open issues. Nothing > major I should be able to figure them out. > > * I did only tests with a 5100 card, other might not yet work.. I will do > tests wie 5300 and 4965 cards later this week. > * 11N has not been tested at all. > * Deauth/disconnect frames are not handled correctly, those yield firmware > errors. The remote side might therefore not be able to clean up correctly, > whichs lead to no answers to probe requests on new scans. > * Encryption of any kind does not yet work. > * Monitor mode/radiotap does not yet work. > * IBSS mode has not been tested. > * iwnfw module is locked somehow on kldunload. > * RF kill switch might not work correctly. > * Manpage needs an update. :) > * Suspend/resume is broken. > > -- > Bernhard > Great job! However, with my 4965, I get a page fault somewhere in iwn4965_set_txpower when I load if_iwn.ko (I'm loading iwnfw.ko manually before loading if_iwn.ko) I'll see if I can gather a bit more info tomorrow. -Brandon From glen.j.barber at gmail.com Mon Oct 19 01:14:03 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Mon Oct 19 01:14:09 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <200910181627.38060.bschmidt@techwires.net> References: <20091009170839.142800@gmx.net> <179b97fb0910142019u455995a4s2cdcf8ba744d98bf@mail.gmail.com> <200910150815.58174.bschmidt@techwires.net> <200910181627.38060.bschmidt@techwires.net> Message-ID: <4ad871310910181814p7dfed61bld2d3e7c04b416008@mail.gmail.com> Howdy! On Sun, Oct 18, 2009 at 10:27 AM, Bernhard Schmidt wrote: > On Thursday 15 October 2009 08:15:57 Bernhard Schmidt wrote: >> .. anyways, I'll post updates on ?sunday. > > Here we go. > > http://techwires.net/~bschmidt/patches/freebsd/iwn/ > > Testers/feedback welcome! > > Code is pretty stable although there are still a few open issues. Nothing > major I should be able to figure them out. > > * I did only tests with a 5100 card, other might not yet work.. I will do > tests wie 5300 and 4965 cards later this week. > * 11N has not been tested at all. > * Deauth/disconnect frames are not handled correctly, those yield firmware > errors. The remote side might therefore not be able to clean up correctly, > whichs lead to no answers to probe requests on new scans. > * Encryption of any kind does not yet work. > * Monitor mode/radiotap does not yet work. > * IBSS mode has not been tested. > * iwnfw module is locked somehow on kldunload. > * RF kill switch might not work correctly. > * Manpage needs an update. :) > * Suspend/resume is broken. > Any thoughts on the errors I get with buildkernel (attached)? The kernel config has no other changes compared to GENERIC than enabling KDB and DDB. Thanks and regards, -- Glen Barber -------------- next part -------------- ===> iwn (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DH AVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/PEGASUS/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/PEGASUS -mno-a lign-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mn o-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-prot ector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-pr ototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fforma t-extensions -c /usr/src/sys/modules/iwn/../../dev/iwn/if_iwn.c cc1: warnings being treated as errors /usr/src/sys/modules/iwn/../../dev/iwn/if_iwn.c: In function 'iwn_read_firmware' : /usr/src/sys/modules/iwn/../../dev/iwn/if_iwn.c:4986: warning: format '%ld' expe cts type 'long int', but argument 4 has type 'size_t' /usr/src/sys/modules/iwn/../../dev/iwn/if_iwn.c:5016: warning: format '%ld' expe cts type 'long int', but argument 4 has type 'size_t' *** Error code 1 Stop in /usr/src/sys/modules/iwn. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/PEGASUS. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. From glen.j.barber at gmail.com Mon Oct 19 01:15:00 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Mon Oct 19 01:15:06 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <4ad871310910181814p7dfed61bld2d3e7c04b416008@mail.gmail.com> References: <20091009170839.142800@gmx.net> <179b97fb0910142019u455995a4s2cdcf8ba744d98bf@mail.gmail.com> <200910150815.58174.bschmidt@techwires.net> <200910181627.38060.bschmidt@techwires.net> <4ad871310910181814p7dfed61bld2d3e7c04b416008@mail.gmail.com> Message-ID: <4ad871310910181814x626c5a60t5e085431e3b267c7@mail.gmail.com> On Sun, Oct 18, 2009 at 9:14 PM, Glen Barber wrote: > Howdy! > > > Any thoughts on the errors I get with buildkernel (attached)? ?The > kernel config has no other changes compared to GENERIC than enabling > KDB and DDB. > > Thanks and regards, > This is 8-STABLE, r198209 by the way. Sorry for not including that initially. -- Glen Barber From julian at elischer.org Mon Oct 19 04:22:37 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Oct 19 04:22:44 2009 Subject: Page fault in IFNET_WLOCK_ASSERT [if.c and pccbb.c] In-Reply-To: References: <4ADAB8E0.3090502@elischer.org> Message-ID: <4ADBE98C.3030404@elischer.org> Harsha wrote: > On Sat, Oct 17, 2009 at 11:42 PM, Julian Elischer wrote: >> Harsha wrote: >>> wrote: >>>> Looks like a NULL pointer dereference, so perhaps a more traditional bug >>>> -- >>>> could you convert ifindex_alloc_locked+0x71 to a line of code? You can do >>>> this using kgdb on the kernel symbols file, perhaps "l >>>> *ifindex_alloc_locked+0x71". >>> It is the for loop in ifindex_alloc_locked() function- >>> for (idx = 1; idx <= V_if_index; idx++) >>> >>> idx is a local variable, so I figured it is V_if_index is what is >>> causing the page fault. It does look like a NULL pointer reference - I >>> see that V_if_index comes from that vnet instance's value and uses >>> the macro VNET_VNET_PTR() down the chain. Since the call chain is >>> coming from a new thread cbb_event_thread, I believe that this >>> thread's vnet context needs to be set using CURVNET_SET(). >> but only if you have options VIMAGE defined. if not then CURVNET_SET() >> is a NOP > I do have the VIMAGE options turned on. > > Can someone tell me what is the right way to add the vnet context to > cbb_event_thread? have you read the vimage porting document at: http://p4db.freebsd.org/fileLogView.cgi?FSPC=//depot/projects/vimage/porting_to_vimage.txt > > I tried adding context in two locations- > > 1. In cbb_insert() as- > CURVNET_SET(TD_TO_VNET(curthread)); > > 2. In if_alloc() as- > CURVNET_SET(TD_TO_VNET(curthread)); > > or as > > ifp = malloc(sizeof(struct ifnet), M_IFNET, M_WAITOK|M_ZERO); > #ifdef VIMAGE > ifp->if_vnet = curvnet; > if (ifp->if_home_vnet == NULL) > ifp->if_home_vnet = curvnet; > CURVNET_SET(ifp->if_vnet); > #endif CURVNET_SET sets curvnet but you are using it already, 3 lines above. > > But in all the cases I get a warning/error about unused variable > 'saved_vnet' like this- > > cc1: warnings being treated as errors > /usr/src/sys/net/if.c: In function 'if_alloc': > /usr/src/sys/net/if.c:418: warning: unused variable 'saved_vnet' > > The backtrace is in the link I posted earlier. > > Thanks, > Harsha From dougb at FreeBSD.org Mon Oct 19 05:34:20 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Oct 19 05:34:27 2009 Subject: Wacky DHCP values that work in windows but not in FreeBSD In-Reply-To: <25ff90d60910122255j5ccae96ar7c58488209768956@mail.gmail.com> References: <4AD3ABD0.7010603@FreeBSD.org> <25ff90d60910122030r1f8511e9ued9535024fa3078a@mail.gmail.com> <4AD410CB.2060105@FreeBSD.org> <25ff90d60910122255j5ccae96ar7c58488209768956@mail.gmail.com> Message-ID: <4ADBFA55.9060601@FreeBSD.org> I'm adding Brooks to the cc list since he is mr. dhcp lately. :) David Horn wrote: > On Tue, Oct 13, 2009 at 1:31 AM, Doug Barton wrote: >> David Horn wrote: >>> Without seeing the actual tcpdump of the dhcp packets, I would guess >>> that this is the Classless Static Route option in DHCPv4 (option 121). >> Ok, I will give the tcpdump option a go as soon as I have a chance. I finally had a chance to look at this again (with your revised tcpdump command line from another mail of yours) and I think you're right. The log (http://people.freebsd.org/~dougb/tcpdump.log) definitely mentions Classless-Static-Route. This was with the stock dhclient in -current. I also tried ISC's 4.1.1b3 just to be sure, and that did not work either. I also tried the various incarnations of route that were suggested on this thread, including all 4 combinations with/without -iface and -hopcount, and none of that worked either. Quick recap, I got the following from dhcp: Your-IP 76.244.161.xxx Subnet-Mask Option 1, length 4: 255.255.0.0 Default-Gateway Option 3, length 4: 151.164.184.xxx Now what DID work was something I tried on a whim. Actually two things worked, 'route add default 76.244.161.1' and (after rebooting) 'route add default 76.244.0.1'. With either of those I could reach things both inside the network (like the name server) and out in the wide world. I have no idea WHY those worked, I suspect that Mike Smith was right and there is some sort of proxy-arp going on, but I'm far from a networking expert. I'll leave the tcpdump log up for a while if y'all think it's useful. I can also test patches for this if someone comes up with a fix. Doug >> Meanwhile, if this is in fact the case how would we make it work in >> FreeBSD? Is there a newer version of DHCP that handles this properly? > > I thought that dhclient originated from ISC, but looking at the > 4.1.1b2 ISC DHCP source and at the OpenBSD dhclient, I did not see > option 121 handling in dhclient. The freebsd copy of both dhclient.c, > and /sbin/dhclient-script there is code for handling this option. I > guess the FreeBSD version split from the ISC version at some point, > and option 121 handling was added (2+ years ago). > > As far as fixing/debugging, it all depends on the exact dhcp options > and values. It might just be a tweak to /sbin/dhclient-script, or it > may be more complicated. > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/dhclient/dhclient.c > Revision 1.21: download - view: text, markup, annotated - select for diffs > Fri Feb 9 17:50:26 2007 UTC (2 years, 8 months ago) by emaste > Branches: MAIN > CVS tags: RELENG_7_BP, RELENG_7_0_BP, RELENG_7_0_0_RELEASE, RELENG_7_0 > Branch point for: RELENG_7 > Diff to: previous 1.20: preferred, colored > Changes since revision 1.20: +68 -0 lines > > Implement RFC3442, the Classless Static Route option. > > The original DHCP specification includes a route option but it supports > only class-based routes. RFC3442 adds support for specifying the netmask > width for each static route. A variable length encoding is used to minimize > the size of this option. > > PR: bin/99534 > Submitted by: Andrey V. Elsukov > Reviewed by: brooks > > ---Dave H > -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From emss.mail at gmail.com Mon Oct 19 09:34:32 2009 From: emss.mail at gmail.com (Eric Masson) Date: Mon Oct 19 09:34:39 2009 Subject: IPSec, nat on enc device Message-ID: <861vkzlula.fsf@srvbsdnanssv.interne.kisoft-services.com> Hello, OpenBSD has support for this kind of setup since last January : http://undeadly.org/cgi?action=article&sid=20090127205841 The commit : http://marc.info/?l=openbsd-cvs&m=123246256228242&w=2 >From what I've understood, pf, depending on version in FreeBSD, could already support natting on enc interfaces. The missing part seems to be laying at the IKE daemon level. Need of ipsec vpns beetween RFC1918 colliding networks is pretty usual these days, so has anyone considered working in this area ? Regards -- je comprend pas ce a quoi sert ce site ou cette boite a lettre.J'y voit plein de messages et autres anneries alors si tu pouvais m'aider et me repondre pour m'expliquer a qui et a quoi servent toutes ses phrases -+- DD in http://www.le-gnu.net : Allo Huston, nous avons un neuneu. -+- From bugmaster at FreeBSD.org Mon Oct 19 11:06:58 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 19 11:08:58 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200910191106.n9JB6vpi063516@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139559 net [tun] several tun(4) interfaces can be created with sa o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139162 net [fwip] [panic] 8.0-RC1 panics if using IP over firewir o kern/139145 net [ip6] IPv6 blackhole / reject routes broken o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139113 net [arp] removing IP alias doesn't delete permanent arp e o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138999 net [libc] lighttpd/php-cgi with freebsd sendfile(2) enabl o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o kern/138694 net [bge] FreeBSD 6.3 release does not recognize Broadcom o amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138676 net [route] after buildworld not work local routes [regres f kern/138666 net [multicast] [panic] not working multicast through igmp o kern/138660 net [igb] igb driver troubles in 8.0-BETA4 o kern/138652 net TCP window scaling value calculated incorrectly? o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138390 net [gif] [patch] NULL pointer dereference in gif_input() o kern/138378 net [altq] [patch] Memory leak in hfsc_class_modify() in f o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR on 8.0-BE o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/138130 net [netinet] [patch] Resource leak in LibAliasRefreshModu o kern/138046 net [tcp] tcp sockets stay in SYN_SENT even after receivin o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137795 net [sctp] [panic] mtx_lock() of destroyed mutex o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137317 net [tcp] logs full of syncache problems o kern/137292 net [ste] DFE-580TX not working properly o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136482 net [age] Attansic L1 Gigabit Ethernet recieves multicasts o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135836 net [bce] bce BCM5709 Watchdog after warm boot - ok after o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/135067 net [patch] [fib] Incorrect KASSERTs in sys/net/route.c o kern/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se o kern/134931 net [route] [fib] Route messages sent to all socket listen o kern/134658 net [bce] bce driver fails on PowerEdge m610 blade. o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134369 net [route] [ip6] IPV6 in Head broken for routing table up o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133786 net [netinet] [patch] ip_input might cause kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132625 net [iwn] iwn drivers don't support setting country o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] [patch] if_sis short cable fix problems with Net s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 357 problems total. From oleg at FreeBSD.org Mon Oct 19 11:09:36 2009 From: oleg at FreeBSD.org (Oleg Bulyzhin) Date: Mon Oct 19 11:11:06 2009 Subject: dummynet dropping too many packets In-Reply-To: <4ACF4A15.1010203@mail.ru> References: <4AC8A76B.3050502@mail.ru> <20091007085902.GA88982@lath.rinet.ru> <4ACC5E23.8090405@mail.ru> <20091007100503.GB88982@lath.rinet.ru> <4ACC6A7B.5050808@mail.ru> <20091007104525.GC88982@lath.rinet.ru> <4ACC7308.6070301@mail.ru> <20091007115425.GD88982@lath.rinet.ru> <4ACF4A15.1010203@mail.ru> Message-ID: <20091019110935.GB87829@lath.rinet.ru> On Fri, Oct 09, 2009 at 07:35:01PM +0500, rihad wrote: > Oleg Bulyzhin wrote: > > On Wed, Oct 07, 2009 at 03:52:56PM +0500, rihad wrote: > > > >> You probably have some special sources of documentation ;-) According to > >> man ipfw, both "netgraph/ngtee" and "pipe" decide the fate of the packet > >> unless one_pass=0. Or do you mean sprinkling smart skiptos here and > >> there? ;-) > > > > you can > > 1) use ng_ether & ng_netflow. (so no need in 'ngtee' rule). > > 2) use 'tee' rule with ng_ksocket & ng_netflow > > > >>> Could you show your 'ipfw show' output? (hide ip addresses if you wish but > >>> keep counters please). > >>> > > > >> Here it is, in its whole glory: > >> > >> 00100 10434423 1484891105 allow ip from any to any via lo0 > >> 00200 2 14 deny ip from any to 127.0.0.0/8 > >> 00300 1 4 deny ip from 127.0.0.0/8 to any > >> 01000 3300039938 327603104711 allow ip from any to any in > >> 01010 26214900 421138433 allow ip from me to any out > >> 01020 5453857 46806278 allow icmp from any to any out > >> 01030 3268289053 327224694165 ngtee 1 ip from any to any out > >> 01040 18681181 1089636054 skipto 1100 ip from table(127) to any out > >> recv bce0 xmit bce1 > >> 01060 777488848 76743392754 pipe tablearg ip from any to table(0) out > >> recv bce0 xmit bce1 > >> 01070 776831109 76682499457 allow ip from any to table(0) out recv > >> bce0 xmit bce1 > >> 01100 13102697 808411842 pipe tablearg ip from any to table(2) out > >> 65535 662648946 66711487830 allow ip from any to any > > > > I guess this one would be better(faster): > > > > 00050 allow ip from any to any in > > 00100 allow ip from any to any via lo0 > > 01010 allow ip from me to any > > 01020 allow icmp from any to any > > 01030 ngtee 1 ip from any to any > > 01035 skipto 1040 ip from any to any recv bce0 xmit bce1 > > 01036 allow ip from any to any > > 01040 skipto 1100 ip from table(127) to any > > 01060 pipe tablearg ip from any to table(0) > > 01070 allow ip from any to any > > 01100 pipe tablearg ip from any to table(2) > > 65535 allow ip from any to any > > > Tried it just now - no visible effect. > 400-700 packet drops per second which is around 5-7 mbps dropped on > output. So I don't think getting rid of one_pass=0 would help at all. One more idea to check: What happens if you rearrange your rules to shape 'in' packets? i.e. use 'in recv bce0' instead of 'out recv bce0 xmit bce1'. -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From eri at freebsd.org Mon Oct 19 14:07:21 2009 From: eri at freebsd.org (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Mon Oct 19 14:07:27 2009 Subject: IPSec, nat on enc device In-Reply-To: <861vkzlula.fsf@srvbsdnanssv.interne.kisoft-services.com> References: <861vkzlula.fsf@srvbsdnanssv.interne.kisoft-services.com> Message-ID: <9a542da30910190707q7eb173d9xf9085d220a213db1@mail.gmail.com> On Mon, Oct 19, 2009 at 9:18 AM, Eric Masson wrote: > Hello, > > OpenBSD has support for this kind of setup since last January : > http://undeadly.org/cgi?action=article&sid=20090127205841 > The commit : > http://marc.info/?l=openbsd-cvs&m=123246256228242&w=2 > > >From what I've understood, pf, depending on version in FreeBSD, could > already support natting on enc interfaces. > > The missing part seems to be laying at the IKE daemon level. I think you should send this email to ipsec-tool mailing list! Basically the daemon should be modified for this and FreeBSD is not the owner of such code. Just my 2c > > Need of ipsec vpns beetween RFC1918 colliding networks is pretty usual > these days, so has anyone considered working in this area ? > > Regards > > -- > ?je comprend pas ce a quoi sert ce site ou cette boite a lettre.J'y voit > ?plein de messages et autres anneries alors si tu pouvais m'aider et me > ?repondre pour m'expliquer a qui et a quoi servent toutes ses phrases > ?-+- DD in http://www.le-gnu.net : Allo Huston, nous avons un neuneu. -+- > -- Ermal From boneandfat at gmail.com Mon Oct 19 15:18:02 2009 From: boneandfat at gmail.com (Z G) Date: Mon Oct 19 15:18:09 2009 Subject: What is the most stable wireless driver beside ath in 8.0 rc1? Message-ID: <95139c170910190751s2f1e59f6o88a3d4b2871f1e19@mail.gmail.com> From emss.mail at gmail.com Mon Oct 19 15:32:23 2009 From: emss.mail at gmail.com (Eric Masson) Date: Mon Oct 19 15:32:29 2009 Subject: IPSec, nat on enc device In-Reply-To: <9a542da30910190707q7eb173d9xf9085d220a213db1@mail.gmail.com> (Ermal =?iso-8859-1?Q?Lu=E7i's?= message of "Mon, 19 Oct 2009 16:07:00 +0200") References: <861vkzlula.fsf@srvbsdnanssv.interne.kisoft-services.com> <9a542da30910190707q7eb173d9xf9085d220a213db1@mail.gmail.com> Message-ID: <86eiozjt6p.fsf@srvbsdnanssv.interne.kisoft-services.com> Ermal Lu?i writes: Hello Ermal, > I think you should send this email to ipsec-tool mailing list! > Basically the daemon should be modified for this and FreeBSD > is not the owner of such code. I know ;) I'll bug them regarding ${suject} as well (some ipsec-tools devs lurk there too) I'm not sure that pf & ipsec stack already support this feature. Maybe bz@ or vanhu@ will shed a light on this point. -- Je veux cr?er une troupe de danse ?rotique! Si vous ?tes pr?s ? vivre des ?motions fortes... si non, la vie continue et... Signature: Un Gros Garcon! -+- CL in GNU - Enlevez le ?Gar? de ma signature pour me r?pondre -+- From atkin901 at yahoo.com Mon Oct 19 15:40:04 2009 From: atkin901 at yahoo.com (Mark Atkinson) Date: Mon Oct 19 15:40:10 2009 Subject: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Message-ID: <200910191540.n9JFe3eZ001118@freefall.freebsd.org> The following reply was made to PR kern/124127; it has been noted by GNATS. From: Mark Atkinson To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Date: Mon, 19 Oct 2009 08:03:58 -0700 (PDT) I am also see this problem on the following, however this on -current built on Aug 25, 2009, so I'm updating to the latest to retest. watchdog timeout (missed Tx interrupts) -- recovering e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto mskc0@pci0:2:0:0: class=0x020000 card=0x81421043 chip=0x436211ab rev=0x15 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = 'Marvell Yukon 88E8053 PCI-E Gigabit Ethernet Controller (88E8053)' class = network subclass = ethernet This is an ASUS P5GD2 Deluxe. Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired); From dhorn2000 at gmail.com Mon Oct 19 15:56:35 2009 From: dhorn2000 at gmail.com (David Horn) Date: Mon Oct 19 15:56:42 2009 Subject: Wacky DHCP values that work in windows but not in FreeBSD In-Reply-To: <4ADBFA55.9060601@FreeBSD.org> References: <4AD3ABD0.7010603@FreeBSD.org> <25ff90d60910122030r1f8511e9ued9535024fa3078a@mail.gmail.com> <4AD410CB.2060105@FreeBSD.org> <25ff90d60910122255j5ccae96ar7c58488209768956@mail.gmail.com> <4ADBFA55.9060601@FreeBSD.org> Message-ID: <25ff90d60910190856t6d0df42cn7e75fc14046220d9@mail.gmail.com> On Mon, Oct 19, 2009 at 1:34 AM, Doug Barton wrote: > I'm adding Brooks to the cc list since he is mr. dhcp lately. :) > > David Horn wrote: >> On Tue, Oct 13, 2009 at 1:31 AM, Doug Barton wrote: >>> David Horn wrote: >>>> Without seeing the actual tcpdump of the dhcp packets, I would guess >>>> that this is the Classless Static Route option in DHCPv4 (option 121). >>> Ok, I will give the tcpdump option a go as soon as I have a chance. > > I finally had a chance to look at this again (with your revised > tcpdump command line from another mail of yours) and I think you're > right. The log (http://people.freebsd.org/~dougb/tcpdump.log) > definitely mentions Classless-Static-Route. This was with the stock > dhclient in -current. I also tried ISC's 4.1.1b3 just to be sure, and > that did not work either. > According to the tcpdump, the client does specify that it supports option 121 in the request, but the server does not in the reply, so my guess was inaccurate. > I also tried the various incarnations of route that were suggested on > this thread, including all 4 combinations with/without -iface and > -hopcount, and none of that worked either. > > Quick recap, I got the following from dhcp: > Your-IP 76.244.161.xxx > Subnet-Mask Option 1, length 4: 255.255.0.0 > Default-Gateway Option 3, length 4: 151.164.184.xxx > > Now what DID work was something I tried on a whim. Actually two things > worked, 'route add default 76.244.161.1' and (after rebooting) 'route > add default 76.244.0.1'. With either of those I could reach things > both inside the network (like the name server) and out in the wide world. > > I have no idea WHY those worked, I suspect that Mike Smith was right > and there is some sort of proxy-arp going on, but I'm far from a > networking expert. > > I'll leave the tcpdump log up for a while if y'all think it's useful. > I can also test patches for this if someone comes up with a fix. > > > Doug > > >>> Meanwhile, if this is in fact the case how would we make it work in >>> FreeBSD? Is there a newer version of DHCP that handles this properly? >> >> I thought that dhclient originated from ISC, but looking at the >> 4.1.1b2 ISC DHCP source and at the OpenBSD dhclient, I did not see >> option 121 handling in dhclient. ?The freebsd copy of both dhclient.c, >> and /sbin/dhclient-script there is code for handling this option. ? I >> guess the FreeBSD version split from the ISC version at some point, >> and option 121 handling was added (2+ years ago). >> >> As far as fixing/debugging, it all depends on the exact dhcp options >> and values. ?It might just be a tweak to /sbin/dhclient-script, or it >> may be more complicated. >> >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/dhclient/dhclient.c >> Revision 1.21: download - view: text, markup, annotated - select for diffs >> Fri Feb 9 17:50:26 2007 UTC (2 years, 8 months ago) by emaste >> Branches: MAIN >> CVS tags: RELENG_7_BP, RELENG_7_0_BP, RELENG_7_0_0_RELEASE, RELENG_7_0 >> Branch point for: RELENG_7 >> Diff to: previous 1.20: preferred, colored >> Changes since revision 1.20: +68 -0 lines >> >> Implement RFC3442, the Classless Static Route option. >> >> The original DHCP specification includes a route option but it supports >> only class-based routes. ?RFC3442 adds support for specifying the netmask >> width for each static route. ?A variable length encoding is used to minimize >> the size of this option. >> >> PR: ? ? ? ? ? ? bin/99534 >> Submitted by: ? Andrey V. Elsukov >> Reviewed by: ? ?brooks >> >> ---Dave H >> > > > -- > > ? ? ? ?Improve the effectiveness of your Internet presence with > ? ? ? ?a domain name makeover! ? ?http://SupersetSolutions.com/ > > From bms at incunabulum.net Mon Oct 19 16:16:49 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon Oct 19 16:17:22 2009 Subject: Native support for AutoIP (aka LLA, RFC 3927). In-Reply-To: References: Message-ID: <4ADC90EA.50406@incunabulum.net> Martin Garon wrote: > I need to implement AutoIP in my embedded FW that uses a snapshot of FreeBSD > 4.4 network stack. > Fredrik Lindberg (shapeshifter.se) implemented some of this for FreeBSD as part of an earlier Google Summer of Code, but I haven't found any free time to integrate it. The code's in his Hg repository, you are probably best off contacting him directly. Some further integration and polishing work is needed to incorporate it into a release. cheers, BMS From alireza.torabi at gmail.com Mon Oct 19 17:12:05 2009 From: alireza.torabi at gmail.com (Alireza Torabi) Date: Mon Oct 19 17:12:15 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <200910181627.38060.bschmidt@techwires.net> References: <20091009170839.142800@gmx.net> <179b97fb0910142019u455995a4s2cdcf8ba744d98bf@mail.gmail.com> <200910150815.58174.bschmidt@techwires.net> <200910181627.38060.bschmidt@techwires.net> Message-ID: Many thanks for your work on this. When do you think you'll have the ecryption support for iwn? (so cheeky of me I know!) Alireza On 10/18/09, Bernhard Schmidt wrote: > On Thursday 15 October 2009 08:15:57 Bernhard Schmidt wrote: >> .. anyways, I'll post updates on sunday. > > Here we go. > > http://techwires.net/~bschmidt/patches/freebsd/iwn/ > > Testers/feedback welcome! > > Code is pretty stable although there are still a few open issues. Nothing > major I should be able to figure them out. > > * I did only tests with a 5100 card, other might not yet work.. I will do > tests wie 5300 and 4965 cards later this week. > * 11N has not been tested at all. > * Deauth/disconnect frames are not handled correctly, those yield firmware > errors. The remote side might therefore not be able to clean up correctly, > whichs lead to no answers to probe requests on new scans. > * Encryption of any kind does not yet work. > * Monitor mode/radiotap does not yet work. > * IBSS mode has not been tested. > * iwnfw module is locked somehow on kldunload. > * RF kill switch might not work correctly. > * Manpage needs an update. :) > * Suspend/resume is broken. > > -- > Bernhard > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From rihad at mail.ru Mon Oct 19 17:45:08 2009 From: rihad at mail.ru (rihad) Date: Mon Oct 19 17:45:14 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091009082743.GB70940@lath.rinet.ru> References: <20091007085902.GA88982@lath.rinet.ru> <4ACC5E23.8090405@mail.ru> <20091007100503.GB88982@lath.rinet.ru> <4ACC6A7B.5050808@mail.ru> <20091007104525.GC88982@lath.rinet.ru> <4ACC7308.6070301@mail.ru> <4ACCC30E.7080504@elischer.org> <4ACCC4F3.3030302@mail.ru> <20091008060608.GA23793@lath.rinet.ru> <4ACE10CF.2030806@elischer.org> <20091009082743.GB70940@lath.rinet.ru> Message-ID: <4ADCA59C.3090601@mail.ru> Oleg Bulyzhin wrote: > One more idea to check: > > What happens if you rearrange your rules to shape 'in' packets? > i.e. use 'in recv bce0' instead of 'out recv bce0 xmit bce1'. Wow, shape incoming packets? That's a good one - the packets could still buffer up waiting to be output. I'm not sure this will eliminate burstiness (if it IS the problem), but I'll no doubt try this if current changes don't prove to be helpful. Currently we've been running running a "ifq_drv_maxlen = 4096;" kernel with HZ=4000 for a few hours, 0 drops so far with around 2700 entries in each of the two IPFW tables (no big surprise so far, we had this with maxlen=1024 too with under 3000 entries). From eri at freebsd.org Mon Oct 19 19:50:47 2009 From: eri at freebsd.org (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Mon Oct 19 19:50:53 2009 Subject: IPSec, nat on enc device In-Reply-To: <86eiozjt6p.fsf@srvbsdnanssv.interne.kisoft-services.com> References: <861vkzlula.fsf@srvbsdnanssv.interne.kisoft-services.com> <9a542da30910190707q7eb173d9xf9085d220a213db1@mail.gmail.com> <86eiozjt6p.fsf@srvbsdnanssv.interne.kisoft-services.com> Message-ID: <9a542da30910191250r62a798a7m586343a800a3d65d@mail.gmail.com> On Mon, Oct 19, 2009 at 5:32 PM, Eric Masson wrote: > Ermal Lu?i writes: > > Hello Ermal, > >> I think you should send this email to ipsec-tool mailing list! >> Basically the daemon should be modified for this and FreeBSD >> is not the owner of such code. > > I know ;) I'll bug them regarding ${suject} as well (some ipsec-tools > devs lurk there too) > > I'm not sure that pf & ipsec stack already support this feature. Maybe > bz@ or vanhu@ will shed a light on this point. > AFAIK, there is not limitation to allow this in the IPSec stack. So it is purely a daemon perspective to instrument the stack for this. -- Ermal From vanhu at FreeBSD.org Mon Oct 19 20:05:52 2009 From: vanhu at FreeBSD.org (vanhu) Date: Mon Oct 19 20:05:59 2009 Subject: IPSec, nat on enc device In-Reply-To: <86eiozjt6p.fsf@srvbsdnanssv.interne.kisoft-services.com> References: <861vkzlula.fsf@srvbsdnanssv.interne.kisoft-services.com> <9a542da30910190707q7eb173d9xf9085d220a213db1@mail.gmail.com> <86eiozjt6p.fsf@srvbsdnanssv.interne.kisoft-services.com> Message-ID: <20091019200549.GA9766@zeninc.net> Hi all. On Mon, Oct 19, 2009 at 05:32:14PM +0200, Eric Masson wrote: [....] > I know ;) I'll bug them regarding ${suject} as well (some ipsec-tools > devs lurk there too) Do you think so ? :-D > I'm not sure that pf & ipsec stack already support this feature. Maybe > bz@ or vanhu@ will shed a light on this point. This is a way to do that, but it needs some stuff on both kernel and userland to be implemented that way. Another way to have this feature is to implement what we call "NAT before VPN": you can configure your kernel (or do it for specific NAT rules if you want to do a more flexible implementation) to do NAT process before doing IPsec stuff. Then, you just write your NAT rules to move local/remote traffic endpoints to distinct networks, and IPsec (both in kernel and userland) will just have to deal with those NATed networks. OpenBSD's way of doing things seems interesting while reading very quickly your link, I'll have to take some more time to really see exactly what they are doing..... Yvan. From eri at freebsd.org Mon Oct 19 20:22:31 2009 From: eri at freebsd.org (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Mon Oct 19 20:22:38 2009 Subject: IPSec, nat on enc device In-Reply-To: <20091019200549.GA9766@zeninc.net> References: <861vkzlula.fsf@srvbsdnanssv.interne.kisoft-services.com> <9a542da30910190707q7eb173d9xf9085d220a213db1@mail.gmail.com> <86eiozjt6p.fsf@srvbsdnanssv.interne.kisoft-services.com> <20091019200549.GA9766@zeninc.net> Message-ID: <9a542da30910191322y1676241cq4448af73d96353e0@mail.gmail.com> > > OpenBSD's way of doing things seems interesting while reading very > quickly your link, I'll have to take some more time to really see > exactly what they are doing..... > > Basically they make aware the daemon and the firewall of the nat. Actually it is more 'user-friendly' to configure though clamsy since you have to do keep the same information in two places, firewall nat rules and the ipsec daemon. You just tell instrument the daemon to inject one 'normal'(out) SA's match traffic coming from your local network and one SA for incoming traffic from remote network with the natted network address. This all is because pf(4) cannot do 'incoming nat' by default. -- Ermal From linimon at FreeBSD.org Mon Oct 19 20:24:38 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Oct 19 20:24:45 2009 Subject: kern/139761: [bce] bce driver on IBM HS22 [No PHY found on Child MII bus] Message-ID: <200910192024.n9JKOc3q049213@freefall.freebsd.org> Old Synopsis: bce driver on IBM HS22 [No PHY found on Child MII bus] New Synopsis: [bce] bce driver on IBM HS22 [No PHY found on Child MII bus] Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Oct 19 20:23:59 UTC 2009 Responsible-Changed-Why: May not be amd64-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=139761 From emss.mail at gmail.com Tue Oct 20 07:08:57 2009 From: emss.mail at gmail.com (Eric Masson) Date: Tue Oct 20 07:09:03 2009 Subject: IPSec, nat on enc device In-Reply-To: <20091019200549.GA9766@zeninc.net> (vanhu@freebsd.org's message of "Mon, 19 Oct 2009 22:05:49 +0200") References: <861vkzlula.fsf@srvbsdnanssv.interne.kisoft-services.com> <9a542da30910190707q7eb173d9xf9085d220a213db1@mail.gmail.com> <86eiozjt6p.fsf@srvbsdnanssv.interne.kisoft-services.com> <20091019200549.GA9766@zeninc.net> Message-ID: <864opuk0e6.fsf@srvbsdnanssv.interne.kisoft-services.com> vanhu writes: 'Lut Yvan, > Another way to have this feature is to implement what we call "NAT > before VPN": you can configure your kernel (or do it for specific NAT > rules if you want to do a more flexible implementation) to do NAT > process before doing IPsec stuff. I've used it last week on a 8.0.2 F200. The major drawback is that an existing nat ruleset must be adapted (nomap rules for vpn networks that dont need nat) and that it can cause issues when activated (a reverse proxy located on a machine behind a bidirectionnal map woes when nat before vpn is activated, that's why I have to setup another box for natted vpns...) > OpenBSD's way of doing things seems interesting while reading very > quickly your link, I'll have to take some more time to really see > exactly what they are doing..... I agree with Ermal that duplicating nat information in pf and isakmpd is suboptimal and probably error-prone, but it seems to me that it's less intrusive than altering the ip stack. -- Suffit d'?tre suffisamment nombreux et tu feras moins le malin. Voter con est une chose, s'en vanter en est une autre... Vous ?tes grotesques et dangereux. -+- Rocou In GNU - Le quantitatif supl?ra-t-il le qualitatif ? -+- From rihad at mail.ru Tue Oct 20 15:41:37 2009 From: rihad at mail.ru (rihad) Date: Tue Oct 20 15:41:45 2009 Subject: dummynet dropping too many packets In-Reply-To: <20091009082743.GB70940@lath.rinet.ru> References: <20091007085902.GA88982@lath.rinet.ru> <4ACC5E23.8090405@mail.ru> <20091007100503.GB88982@lath.rinet.ru> <4ACC6A7B.5050808@mail.ru> <20091007104525.GC88982@lath.rinet.ru> <4ACC7308.6070301@mail.ru> <4ACCC30E.7080504@elischer.org> <4ACCC4F3.3030302@mail.ru> <20091008060608.GA23793@lath.rinet.ru> <4ACE10CF.2030806@elischer.org> <20091009082743.GB70940@lath.rinet.ru> Message-ID: <4ADDDA2C.3020206@mail.ru> I'm so happy today: finally running a "ifp->if_snd.ifq_drv_maxlen = 4096;" and HZ=4000 kernel with 4100+ online users @500+ mbps, and, most importantly, with absolutely 0 drops since boot time! ;-) Even if drops do come in, I'll know where to look first. I'd like to express my gratitude to Robert Watson for pointing out the "ifnet transmit queue sizes" issue, to others who suggested the problem might be in dummynet's burstiness, and yet to others who tried hard to help with other suggestions. Thank you, folks! Tomorrow I'm going to suggest to my boss to donate some $$$ to the FreeBSD Foundation: http://www.freebsdfoundation.org/donate/ From bz at FreeBSD.org Tue Oct 20 18:00:08 2009 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Tue Oct 20 18:00:15 2009 Subject: IPSec, nat on enc device In-Reply-To: <864opuk0e6.fsf@srvbsdnanssv.interne.kisoft-services.com> References: <861vkzlula.fsf@srvbsdnanssv.interne.kisoft-services.com> <9a542da30910190707q7eb173d9xf9085d220a213db1@mail.gmail.com> <86eiozjt6p.fsf@srvbsdnanssv.interne.kisoft-services.com> <20091019200549.GA9766@zeninc.net> <864opuk0e6.fsf@srvbsdnanssv.interne.kisoft-services.com> Message-ID: <20091020174351.T5956@maildrop.int.zabbadoz.net> On Tue, 20 Oct 2009, Eric Masson wrote: Good evening, > vanhu writes: > > 'Lut Yvan, > >> Another way to have this feature is to implement what we call "NAT >> before VPN": you can configure your kernel (or do it for specific NAT >> rules if you want to do a more flexible implementation) to do NAT >> process before doing IPsec stuff. > > I've used it last week on a 8.0.2 F200. The major drawback is that an > existing nat ruleset must be adapted (nomap rules for vpn networks that > dont need nat) and that it can cause issues when activated > (a reverse proxy located on a machine behind a bidirectionnal map woes > when nat before vpn is activated, that's why I have to setup another box > for natted vpns...) > >> OpenBSD's way of doing things seems interesting while reading very >> quickly your link, I'll have to take some more time to really see >> exactly what they are doing..... > > I agree with Ermal that duplicating nat information in pf and isakmpd is > suboptimal and probably error-prone, but it seems to me that it's less > intrusive than altering the ip stack. I only had a quick look at the commit message being on the road. I think Open seems to move further and further in the direction to be an operating system around pf, rather than pf being a firewall implementation for the OS, in some areas. That kind of worries me - also for further code sharing wrt to pf(4). What I said before and will repeat is that if you want to use NAT and VPN you want to do inside NAT (addmittingly handling the local machine is a different story). I have done that years ago with ipfw. Then your SA works on the NAT IP. I used it to avoid formerly RFC1918 address collisions by NATing to an unrouted public IP for just the VPNs. THe NAT IP will not be bound to any interface at all. There is a reason major vendors have been doing inside and outside NAT for ages now. That pf cannot do that is bad and a design problem there. The "commit Theo calls me insane for" moves into the direction of fixing that but when I talked to OpenBSD people at EuroBSDCon they said something along the lines of "it's not entirely there yet and still disabled because there are a few things that would work entirely as expected". There is abosultely no need to change the IP stack to accomplish that. If you want to do it with pf + enc + NAT you can actually do that even without patches but a bad ugly not to publish hack, that you will most likely only want to do if you control all endpoints: you add two policies: one with your internal network and one with your NAT IP on both sides. racoon , configured correctly, will negotiate the SA and share it for the tunnel endpoints for both policies. The remote destination will never see a packet with a src of your internal IPs but it will have a policy for it - else negotiation would fail. You may need to assure that no packets travel your way with the 1st, internal, policy in the firewall. What I see with the OpenBSD change is that their hack does nothing but get rid of the 1st policy for the internal network on the peer. Not sure if they still need it locally or if they hacked the stack for that; from what I see FreeBSD would have to do that. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From bschmidt at techwires.net Tue Oct 20 20:47:54 2009 From: bschmidt at techwires.net (Bernhard Schmidt) Date: Tue Oct 20 20:48:01 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <200910181627.38060.bschmidt@techwires.net> References: <20091009170839.142800@gmx.net> <200910150815.58174.bschmidt@techwires.net> <200910181627.38060.bschmidt@techwires.net> Message-ID: <200910202247.45866.bschmidt@techwires.net> On Sunday 18 October 2009 16:27:37 Bernhard Schmidt wrote: > On Thursday 15 October 2009 08:15:57 Bernhard Schmidt wrote: > > .. anyways, I'll post updates on sunday. > > Here we go. Update: * All reported issues should now be fixed, please verify. * WPA does work. Still open: * Test reports welcome, especially with 4965, 5150, 5300 and 5350. At this point, if no issue come up, the driver has the same functionality as the in tree one. http://techwires.net/~bschmidt/patches/freebsd/iwn/sys/ or http://techwires.net/~bschmidt/patches/freebsd/iwn/iwn-20091020.tar.gz -- Bernhard From dhorn2000 at gmail.com Tue Oct 20 23:11:36 2009 From: dhorn2000 at gmail.com (David Horn) Date: Tue Oct 20 23:11:42 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <200910202247.45866.bschmidt@techwires.net> References: <20091009170839.142800@gmx.net> <200910150815.58174.bschmidt@techwires.net> <200910181627.38060.bschmidt@techwires.net> <200910202247.45866.bschmidt@techwires.net> Message-ID: <25ff90d60910201611l1aeaac34j250f8c3aa566a3e6@mail.gmail.com> On Tue, Oct 20, 2009 at 4:47 PM, Bernhard Schmidt wrote: > On Sunday 18 October 2009 16:27:37 Bernhard Schmidt wrote: >> On Thursday 15 October 2009 08:15:57 Bernhard Schmidt wrote: >> > .. anyways, I'll post updates on ?sunday. >> >> Here we go. > > Update: > * All reported issues should now be fixed, please verify. > * WPA does work. 4965 with mode 11g WPA2/AES works well on 2.4Ghz (Have not tried 5Ghz/11a or 5Ghz/11n) > > Still open: > * Test reports welcome, especially with 4965, 5150, 5300 and 5350. > > At this point, if no issue come up, the driver has the same functionality as > the in tree one. Any thoughts on IBSS or 11n mode support ? (I could not get 4965 11ng mode to work, and IBSS support is disabled in the drivercaps) Of course, this is on-par with the in-tree iwn driver as well. The only new issue I have found so far is that I must manually load iwnfw.ko before loading if_iwn.ko (the module depend used to work on the in-tree driver) Thanks for your work on this driver! ---Dave H From bschmidt at techwires.net Wed Oct 21 06:33:51 2009 From: bschmidt at techwires.net (Bernhard Schmidt) Date: Wed Oct 21 06:33:58 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <25ff90d60910201611l1aeaac34j250f8c3aa566a3e6@mail.gmail.com> References: <20091009170839.142800@gmx.net> <200910202247.45866.bschmidt@techwires.net> <25ff90d60910201611l1aeaac34j250f8c3aa566a3e6@mail.gmail.com> Message-ID: <200910210833.44121.bschmidt@techwires.net> On Wednesday 21 October 2009 01:11:34 David Horn wrote: > On Tue, Oct 20, 2009 at 4:47 PM, Bernhard Schmidt > > wrote: > > On Sunday 18 October 2009 16:27:37 Bernhard Schmidt wrote: > >> On Thursday 15 October 2009 08:15:57 Bernhard Schmidt wrote: > >> > .. anyways, I'll post updates on sunday. > >> > >> Here we go. > > > > Update: > > * All reported issues should now be fixed, please verify. > > * WPA does work. > > 4965 with mode 11g WPA2/AES works well on 2.4Ghz (Have not tried > 5Ghz/11a or 5Ghz/11n) > > > Still open: > > * Test reports welcome, especially with 4965, 5150, 5300 and 5350. > > > > At this point, if no issue come up, the driver has the same functionality > > as the in tree one. > > Any thoughts on IBSS or 11n mode support ? (I could not get 4965 11ng > mode to work, and IBSS support is disabled in the drivercaps) Of > course, this is on-par with the in-tree iwn driver as well. Have not spend time on that one, another time maybe. > The only new issue I have found so far is that I must manually load > iwnfw.ko before loading if_iwn.ko (the module depend used to work on > the in-tree driver) Hmm.. that is probably related to the rename of the firmware image, iwnfw-5000 instead of iwnfw. Is MODULE_DEPEND(iwn, iwnfw, 1, 1, 1); an option there? > Thanks for your work on this driver! You're welcome :) -- Bernhard From dhorn2000 at gmail.com Wed Oct 21 07:29:15 2009 From: dhorn2000 at gmail.com (David Horn) Date: Wed Oct 21 07:29:25 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <200910210833.44121.bschmidt@techwires.net> References: <20091009170839.142800@gmx.net> <200910202247.45866.bschmidt@techwires.net> <25ff90d60910201611l1aeaac34j250f8c3aa566a3e6@mail.gmail.com> <200910210833.44121.bschmidt@techwires.net> Message-ID: <25ff90d60910210029t5f8f67d0nd17b537ecaacdee9@mail.gmail.com> On Wed, Oct 21, 2009 at 2:33 AM, Bernhard Schmidt wrote: > On Wednesday 21 October 2009 01:11:34 David Horn wrote: >> On Tue, Oct 20, 2009 at 4:47 PM, Bernhard Schmidt >> >> wrote: >> > On Sunday 18 October 2009 16:27:37 Bernhard Schmidt wrote: >> >> On Thursday 15 October 2009 08:15:57 Bernhard Schmidt wrote: >> >> > .. anyways, I'll post updates on ?sunday. >> >> >> >> Here we go. >> > >> > Update: >> > * All reported issues should now be fixed, please verify. >> > * WPA does work. >> >> 4965 with mode 11g WPA2/AES works well on 2.4Ghz (Have not tried >> 5Ghz/11a or 5Ghz/11n) >> >> > Still open: >> > * Test reports welcome, especially with 4965, 5150, 5300 and 5350. >> > >> > At this point, if no issue come up, the driver has the same functionality >> > as the in tree one. >> >> Any thoughts on IBSS or 11n mode support ? ?(I could not get 4965 11ng >> mode to work, and IBSS support is disabled in the drivercaps) ?Of >> course, this is on-par with the in-tree iwn driver as well. > > Have not spend time on that one, another time maybe. > >> The only new issue I have found so far is that I must manually load >> iwnfw.ko before loading if_iwn.ko (the module depend used to work on >> the in-tree driver) > > Hmm.. that is probably related to the rename of the firmware image, iwnfw-5000 > instead of iwnfw. Is MODULE_DEPEND(iwn, iwnfw, 1, 1, 1); an option there? MODULE_DEPEND(iwn, iwnfw_fw, 1, 1, 1) added to if_iwn.c fixes it nicely (note: iwnfw_fw not just iwnfw). It turns out the original driver loaded the iwnfw.ko module as part of firmware_get() since the firmware module name matched the first firmware image name (see firmware.h comments). Looking at the other drivers, the other option is to break up the firmware images into unique kernel modules (e.g. ral or iwi), and allow firmware_get() to do the load. I would think that this would reduce kernel memory usage as well (several individual firmware modules vs all firmware images in one module). Just a thought. --Dave H From bschmidt at techwires.net Wed Oct 21 08:12:23 2009 From: bschmidt at techwires.net (Bernhard Schmidt) Date: Wed Oct 21 08:12:30 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <25ff90d60910210029t5f8f67d0nd17b537ecaacdee9@mail.gmail.com> References: <20091009170839.142800@gmx.net> <200910210833.44121.bschmidt@techwires.net> <25ff90d60910210029t5f8f67d0nd17b537ecaacdee9@mail.gmail.com> Message-ID: <200910211012.15474.bschmidt@techwires.net> On Wednesday 21 October 2009 09:29:13 David Horn wrote: > >> The only new issue I have found so far is that I must manually load > >> iwnfw.ko before loading if_iwn.ko (the module depend used to work on > >> the in-tree driver) > > > > Hmm.. that is probably related to the rename of the firmware image, > > iwnfw-5000 instead of iwnfw. Is MODULE_DEPEND(iwn, iwnfw, 1, 1, 1); an > > option there? > > MODULE_DEPEND(iwn, iwnfw_fw, 1, 1, 1) > > added to if_iwn.c fixes it nicely (note: iwnfw_fw not just iwnfw). It > turns out the original driver loaded the iwnfw.ko module as part of > firmware_get() since the firmware module name matched the first > firmware image name (see firmware.h comments). Looking at the other > drivers, the other option is to break up the firmware images into > unique kernel modules (e.g. ral or iwi), and allow firmware_get() to > do the load. I would think that this would reduce kernel memory usage > as well (several individual firmware modules vs all firmware images in > one module). Just a thought. Any "offical" opinions on that one? Should we break iwnfw up into individual modules? -- Bernhard From rpaulo at freebsd.org Wed Oct 21 19:37:28 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Wed Oct 21 19:38:01 2009 Subject: What is the most stable wireless driver beside ath in 8.0 rc1? In-Reply-To: <95139c170910190751s2f1e59f6o88a3d4b2871f1e19@mail.gmail.com> References: <95139c170910190751s2f1e59f6o88a3d4b2871f1e19@mail.gmail.com> Message-ID: For PCI: ral(4), most likely. -- Rui Paulo From rpaulo at freebsd.org Wed Oct 21 19:40:21 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Wed Oct 21 19:40:27 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <200910211012.15474.bschmidt@techwires.net> References: <20091009170839.142800@gmx.net> <200910210833.44121.bschmidt@techwires.net> <25ff90d60910210029t5f8f67d0nd17b537ecaacdee9@mail.gmail.com> <200910211012.15474.bschmidt@techwires.net> Message-ID: On 21 Oct 2009, at 09:12, Bernhard Schmidt wrote: > On Wednesday 21 October 2009 09:29:13 David Horn wrote: >>>> The only new issue I have found so far is that I must manually load >>>> iwnfw.ko before loading if_iwn.ko (the module depend used to work >>>> on >>>> the in-tree driver) >>> >>> Hmm.. that is probably related to the rename of the firmware image, >>> iwnfw-5000 instead of iwnfw. Is MODULE_DEPEND(iwn, iwnfw, 1, 1, >>> 1); an >>> option there? >> >> MODULE_DEPEND(iwn, iwnfw_fw, 1, 1, 1) >> >> added to if_iwn.c fixes it nicely (note: iwnfw_fw not just iwnfw). >> It >> turns out the original driver loaded the iwnfw.ko module as part of >> firmware_get() since the firmware module name matched the first >> firmware image name (see firmware.h comments). Looking at the other >> drivers, the other option is to break up the firmware images into >> unique kernel modules (e.g. ral or iwi), and allow firmware_get() to >> do the load. I would think that this would reduce kernel memory >> usage >> as well (several individual firmware modules vs all firmware images >> in >> one module). Just a thought. > > Any "offical" opinions on that one? Should we break iwnfw up into > individual > modules? I believe so. Thanks for your work. I hope this can be in HEAD soon. Regards, -- Rui Paulo From glen.j.barber at gmail.com Thu Oct 22 00:51:22 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Thu Oct 22 00:51:29 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: References: <20091009170839.142800@gmx.net> <200910210833.44121.bschmidt@techwires.net> <25ff90d60910210029t5f8f67d0nd17b537ecaacdee9@mail.gmail.com> <200910211012.15474.bschmidt@techwires.net> Message-ID: <4ad871310910211751t31b17133kf994728b2cbf2b39@mail.gmail.com> Howdy, On Wed, Oct 21, 2009 at 3:40 PM, Rui Paulo wrote: > On 21 Oct 2009, at 09:12, Bernhard Schmidt wrote: > >> On Wednesday 21 October 2009 09:29:13 David Horn wrote: >>>>> >>>>> The only new issue I have found so far is that I must manually load >>>>> iwnfw.ko before loading if_iwn.ko (the module depend used to work on >>>>> the in-tree driver) I just had my first bit of quirkiness with my 5100 (console output below). The past few days I was spending some time at my local cafe on battery power without an issue. No connectivity issues the past two days, most of which has been on battery power (approximately 1.5 hours each day). I doubt that is relevant, but I was more intrigued as the output and connectivity loss occurred on AC power. I have made no changes to the system (including source upgrades) since patching this driver. > > Thanks for your work. I hope this can be in HEAD soon. > I've been using this on -STABLE, for what it's worth, with no issues (other than above, which was solved with 'netif restart wlan0'.) Cheers. pegasus % uname -a FreeBSD pegasus 8.0-RC1 FreeBSD 8.0-RC1 #14 r198164M: Mon Oct 19 16:09:19 EDT 2009 root@pegasus:/usr/obj/usr/src/sys/PEGASUS i386 -- console -- iwn0: need multicast update callback firmware error log: error type = "SYSASSERT" (0x00000005) program counter = 0x00001924 source line = 0x00000201 error data = 0x0000000000000201 branch link = 0x0000191200001912 interrupt link = 0x0000090E00000000 time = 1619819137 driver status: tx ring 0: qid=0 cur=219 queued=0 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=2 queued=0 tx ring 4: qid=4 cur=191 queued=0 tx ring 5: qid=5 cur=0 queued=0 tx ring 6: qid=6 cur=0 queued=0 tx ring 7: qid=7 cur=0 queued=0 tx ring 8: qid=8 cur=0 queued=0 tx ring 9: qid=9 cur=0 queued=0 tx ring 10: qid=10 cur=0 queued=0 tx ring 11: qid=11 cur=0 queued=0 tx ring 12: qid=12 cur=0 queued=0 tx ring 13: qid=13 cur=0 queued=0 tx ring 14: qid=14 cur=0 queued=0 tx ring 15: qid=15 cur=0 queued=0 tx ring 16: qid=16 cur=0 queued=0 tx ring 17: qid=17 cur=0 queued=0 tx ring 18: qid=18 cur=0 queued=0 tx ring 19: qid=19 cur=0 queued=0 rx ring: cur=62 iwn0: need multicast update callback Oct 21 19:37:44 pegasus su: gbarber to root on /dev/pts/2 Oct 21 19:37:53 pegasus dhclient[4763]: receive_packet failed on wlan0: Device not configured Oct 21 19:37:53 pegasus wpa_supplicant[4639]: Failed to disable WPA in the driver. Oct 21 19:37:53 pegasus dhclient[4763]: ioctl(SIOCGIFFLAGS) on wlan0: Operation not permitted Oct 21 19:37:53 pegasus dhclient[4763]: Interface wlan0 no longer appears valid. Oct 21 19:37:53 pegasus dhclient[4763]: No live interfaces to poll on - exiting. -- wpa_supplicant.conf -- pegasus % less wpa.conf ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel ap_scan=1 ## Home network={ ssid="" key_mgmt=WPA-PSK psk="" priority=42 } ## B&N network={ ssid="" key_mgmt=NONE priority=2 } ## Drexel network={ ssid="" key_mgmt=NONE priority=12 wep_tx_keyidx=0 wep_key0=sekrit } -- Glen Barber From brueffer at FreeBSD.org Thu Oct 22 06:17:39 2009 From: brueffer at FreeBSD.org (brueffer@FreeBSD.org) Date: Thu Oct 22 06:17:49 2009 Subject: kern/138390: [gif] [patch] NULL pointer dereference in gif_input() in file sys/net/if_gif.c Message-ID: <200910220617.n9M6HdT0044241@freefall.freebsd.org> Synopsis: [gif] [patch] NULL pointer dereference in gif_input() in file sys/net/if_gif.c State-Changed-From-To: open->patched State-Changed-By: brueffer State-Changed-When: Thu Oct 22 08:17:12 CEST 2009 State-Changed-Why: Committed, thanks! Responsible-Changed-From-To: freebsd-net->brueffer Responsible-Changed-By: brueffer Responsible-Changed-When: Thu Oct 22 08:17:12 CEST 2009 Responsible-Changed-Why: MFC reminder. http://www.freebsd.org/cgi/query-pr.cgi?pr=138390 From lejatorn at gmail.com Thu Oct 22 08:03:15 2009 From: lejatorn at gmail.com (Mathieu L.) Date: Thu Oct 22 08:03:23 2009 Subject: problem with pptp, using mpd Message-ID: <95a7a803a4435ee1e8e7a161174994ae@iram.fr> Hello, I am having trouble using mpd, I want to connect to a vpn with pptp (vpn service provided by relakks.com). Here is my configuration: mpd.conf: ######################### default: load relakks relakks: create bundle static B1 set iface route default set ipcp ranges 0.0.0.0/0 0.0.0.0/0 # Enable Microsoft Point-to-Point encryption (MPPE) set bundle enable compression set ccp yes mppc set mppc yes e128 set bundle enable crypt-reqd set mppc yes stateless create link static L1 pptp set link action bundle B1 # Enable both sides to authenticat each other with CHAP set auth disable internal set auth authname "lejatorn" set auth password "XXXXXXXX" set link no pap set link no eap set link yes chap set link mtu 1460 set link keep-alive 10 75 set link max-redial 0 # Configure PPTP and open link set pptp peer pptp.relakks.com set pptp disable windowing set link enable incoming open and here is the output when I start mpd5: process 88409 started, version 5.3 (root@XXXXX.XXX 20:41 20-Oct-2009) Label 'startup' not found [B1] Bundle: Interface ng0 created PPTP: waiting for connection on 0.0.0.0 1723 [L1] [L1] Link: OPEN event [L1] LCP: Open event [L1] LCP: state change Initial --> Starting [L1] LCP: LayerStart [L1] PPTP call successful [L1] LCP: Up event [L1] LCP: state change Starting --> Req-Sent [L1] LCP: SendConfigReq #1 [L1] ACFCOMP [L1] PROTOCOMP [L1] ACCMAP 0x000a0000 [L1] MRU 1500 [L1] MAGICNUM 200f22c0 [L1] AUTHPROTO CHAP MSOFTv2 [L1] LCP: rec'd Configure Ack #1 (Req-Sent) [L1] ACFCOMP [L1] PROTOCOMP [L1] ACCMAP 0x000a0000 [L1] MRU 1500 [L1] MAGICNUM 200f22c0 [L1] AUTHPROTO CHAP MSOFTv2 [L1] LCP: state change Req-Sent --> Ack-Rcvd [L1] LCP: state change Ack-Rcvd --> Req-Sent [L1] LCP: SendConfigReq #2 [L1] ACFCOMP [L1] PROTOCOMP [L1] ACCMAP 0x000a0000 [L1] MRU 1500 [L1] MAGICNUM 200f22c0 [L1] AUTHPROTO CHAP MSOFTv2 [L1] LCP: rec'd Configure Ack #2 (Req-Sent) [L1] ACFCOMP [L1] PROTOCOMP [L1] ACCMAP 0x000a0000 [L1] MRU 1500 [L1] MAGICNUM 200f22c0 [L1] AUTHPROTO CHAP MSOFTv2 [L1] LCP: state change Req-Sent --> Ack-Rcvd [L1] LCP: rec'd Configure Request #1 (Ack-Rcvd) [L1] ACCMAP 0x00000000 [L1] AUTHPROTO CHAP MSOFTv2 [L1] MAGICNUM dc6a4d04 [L1] PROTOCOMP [L1] ACFCOMP [L1] LCP: SendConfigAck #1 [L1] ACCMAP 0x00000000 [L1] AUTHPROTO CHAP MSOFTv2 [L1] MAGICNUM dc6a4d04 [L1] PROTOCOMP [L1] ACFCOMP [L1] LCP: state change Ack-Rcvd --> Opened [L1] LCP: auth: peer wants CHAP, I want CHAP [L1] CHAP: sending CHALLENGE #1 len: 29 [L1] LCP: LayerUp [L1] CHAP: rec'd CHALLENGE #27 len: 30 [L1] Name: "localhost" [L1] CHAP: Using authname "lejatorn" [L1] CHAP: sending RESPONSE #27 len: 62 [L1] CHAP: rec'd RESPONSE #1 len: 63 [L1] Name: "localhost" [L1] AUTH: ran out of backends [L1] CHAP: Auth return status: failed [L1] CHAP: Reply message: E=691 R=0 M=Login incorrect [L1] CHAP: sending FAILURE #1 len: 31 [L1] LCP: authorization failed [L1] LCP: parameter negotiation failed [L1] LCP: state change Opened --> Stopping [L1] LCP: SendTerminateReq #3 [L1] LCP: LayerDown [L1] rec'd proto CHAP during terminate phase [L1] LCP: rec'd Terminate Request #2 (Stopping) [L1] LCP: SendTerminateAck #4 [L1] LCP: rec'd Terminate Ack #3 (Stopping) [L1] LCP: state change Stopping --> Stopped [L1] LCP: LayerFinish [L1] PPTP call terminated [L1] Link: DOWN event [L1] LCP: Down event [L1] LCP: state change Stopped --> Starting [L1] LCP: LayerStart [L1] Link: reconnection attempt 1 in 2 seconds It seems that the authentication is failing but I don't know why as the login and password are correct (I tested them with pptp/pon on Debian, it worked fine). One thing that puzzles me is the [L1] Name: "localhost" line, as if "localhost" was used as a login or something... Can anyone help please? Regards, Mathieu From brendan.kennedy at gmail.com Thu Oct 22 09:37:33 2009 From: brendan.kennedy at gmail.com (Brendan Kennedy) Date: Thu Oct 22 09:37:39 2009 Subject: FreeBSD 7.1 mbuf_cluster memory leak Message-ID: Hi all, I'm having a problem with a crypto driver and netipsec/racoon. At high data rates (1Gig of traffic, 64bit packets) we seem to be leaking 'mbuf_cluster's. These are allocated/freed by either netipsec I think. At low data rates, 'mbuf_cluster's are not used, so we don't have this problem. I just have a few questions around this issue: 1) What is the difference between mbuf and mbuf_packet? 1) Why am I getting mbuf_cluster memory being used when the packets are so small? 2) Is netipsec grouping the 64bit IP packets into a single ipsec packet? 3) Should my crypto driver be dealing with the mbuf_cluster any differently than a linked list of data (e.g. should a digest be added at the bottom of each fragment)? Regards, Brendan From nms+bsd at otdel-1.org Thu Oct 22 13:00:12 2009 From: nms+bsd at otdel-1.org (Nikolai Saoukh) Date: Thu Oct 22 13:00:18 2009 Subject: kern/139204: DHCP server replies rejected, ARP entry lost before max_age Message-ID: <200910221300.n9MD05X9023309@freefall.freebsd.org> The following reply was made to PR kern/139204; it has been noted by GNATS. From: Nikolai Saoukh To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/139204: DHCP server replies rejected, ARP entry lost before max_age Date: Thu, 22 Oct 2009 16:57:52 +0400 Looks like recent changes in CURRENT fixed the problems. This PR can be closed after MFCs. From rpaulo at freebsd.org Thu Oct 22 15:30:48 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Thu Oct 22 15:31:01 2009 Subject: Network scripts gone wrong Message-ID: <885E4649-C66D-4C6F-8E08-168BCE679216@freebsd.org> I don't have time to debug this today, but it seems that latest 9.0 has problems with wireless devices: wlan0: Ethernet address: 00:0b:6b:2d:dc:d8 Starting Network: lo0 ath0 ath1 ath2 npe0 npe1. lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 ath0: flags=8843 metric 0 mtu 2290 ether 00:0b:6b:2d:dc:d8 media: IEEE 802.11 Wireless Ethernet autoselect mode 11a status: running ath1: flags=8802 metric 0 mtu 2290 ether 00:17:f2:9c:a7:62 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ath2: flags=8802 metric 0 mtu 2290 ether 00:17:f2:9c:a7:6b media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier npe0: flags=8802 metric 0 mtu 1500 options=8 ether 00:d0:12:04:e4:7d media: Ethernet autoselect (100baseTX ) status: active npe1: flags=8802 metric 0 mtu 1500 options=8 ether 00:d0:12:03:e3:7c media: Ethernet autoselect (none) status: no carrier Starting devd. Starting Network: ath1. ath1: flags=8802 metric 0 mtu 2290 ether 00:17:f2:9c:a7:62 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier Starting Network: ath1. ath1: flags=8802 metric 0 mtu 2290 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier Starting Network: ath2. ath2: flags=8802 metric 0 mtu 2290 ether 00:17:f2:9c:a7:6b media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier Starting Network: ath2. ath2: flags=8802 metric 0 mtu 2290 ether 00:17:f2:9c:a7:6b media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier Starting Network: npe0. npe0: flags=8802 metric 0 mtu 1500 options=8 ether 00:d0:12:04:e4:7d media: Ethernet autoselect (100baseTX ) status: active Starting Network: npe1. npe1: flags=8802 metric 0 mtu 1500 options=8 ether 00:d0:12:03:e3:7c media: Ethernet autoselect (none) status: no carrier All I have in rc.conf is (network wise): background_dhclient_npe1="YES" # Start dhcp client in the background. defaultroute_delay="0" wlans_ath0="wlan0" create_args_wlan0="wlanmode mesh" ifconfig_wlan0="meshid freebsd-mesh channel 36 10.2.0.103/24" -- Rui Paulo From artem at aws-net.org.ua Thu Oct 22 15:42:23 2009 From: artem at aws-net.org.ua (Artyom Viklenko) Date: Thu Oct 22 15:42:31 2009 Subject: problem with pptp, using mpd In-Reply-To: <95a7a803a4435ee1e8e7a161174994ae@iram.fr> References: <95a7a803a4435ee1e8e7a161174994ae@iram.fr> Message-ID: <4AE07D57.6070709@aws-net.org.ua> Mathieu L. wrote: > Hello, > > I am having trouble using mpd, I want to connect to a vpn with pptp > (vpn service provided by relakks.com). > > Here is my configuration: > > mpd.conf: > ######################### > > default: > load relakks > > relakks: > create bundle static B1 > set iface route default > set ipcp ranges 0.0.0.0/0 0.0.0.0/0 > # Enable Microsoft Point-to-Point encryption (MPPE) > set bundle enable compression > set ccp yes mppc > set mppc yes e128 > set bundle enable crypt-reqd > set mppc yes stateless > > create link static L1 pptp > set link action bundle B1 > # Enable both sides to authenticat each other with CHAP > set auth disable internal > set auth authname "lejatorn" > set auth password "XXXXXXXX" > set link no pap > set link no eap > set link yes chap > set link mtu 1460 > set link keep-alive 10 75 > set link max-redial 0 > # Configure PPTP and open link > set pptp peer pptp.relakks.com > set pptp disable windowing > set link enable incoming > open > > try to add these: set auth authname set link enable no-orig-auth -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org From arun.anirudhan at gmail.com Thu Oct 22 17:42:49 2009 From: arun.anirudhan at gmail.com (Arun Anirudhan) Date: Thu Oct 22 17:42:56 2009 Subject: rip_input Message-ID: Hello I have just started programming in Kernel Level in FreeBSD. I'm trying to hook rip_input and extract the fields in IP header. I just tried to print the ip_len. This is the code, but its not getting printed. Please help me... --------------------------------- #include #include #include #include #include #include #include #include #include #include #include #include extern struct protosw inetsw[]; pr_input_t rip_input_hook; void rip_input_hook(struct mbuf *m, int off) { struct ip *icp; int hlen=off; int l; //m->m_len-=hlen; //m->m_data+=hlen; icp=mtod(m, struct ip *); l=icp->ip_len; //m->m_len+=hlen; //m->m_data-=hlen; uprintf("%d.\n",l); } static int load(struct module *module, int cmd, void *arg) { int error = 0; switch (cmd) { case MOD_LOAD: inetsw[ip_protox[IPPROTO_RAW]].pr_input = rip_input_hook; break; case MOD_UNLOAD: inetsw[ip_protox[IPPROTO_RAW]].pr_input = rip_input; break; default: error = EOPNOTSUPP; break; } return (error); } static moduledata_t rip_input_hook_mod = { "rip_input_hook", load, NULL}; DECLARE_MODULE(rip_input_hook,rip_input_hook_mod,SI_SUB_DRIVERS,SI_ORDER_MIDDLE); -- With regards Arun Anirudhan MTech Student, NIT Calicut 9495983679 From arun.anirudhan at gmail.com Thu Oct 22 18:01:56 2009 From: arun.anirudhan at gmail.com (Arun Anirudhan) Date: Thu Oct 22 18:02:02 2009 Subject: rip_input In-Reply-To: <4AE09C03.6050201@elischer.org> References: <4AE09C03.6050201@elischer.org> Message-ID: When I make void rip_input_hook(struct mbuf *m, int off) to void rip_input_hook(struct mbuf *m) its showing error!! --------------- rip_input_hook.c:20: error: conflicting types for 'rip_input_hook' rip_input_hook.c:17: error: previous declaration of 'rip_input_hook' was here rip_input_hook.c: In function 'rip_input_hook': rip_input_hook.c:31: error: too few arguments to function 'rip_input' rip_input_hook.c: In function 'load': rip_input_hook.c:40: warning: assignment from incompatible pointer type *** Error code 1 ------------------- Its given in a book that rip_input(m) only... On Thu, Oct 22, 2009 at 11:23 PM, Julian Elischer wrote: > Arun Anirudhan wrote: > >> Hello >> I have just started programming in Kernel Level in FreeBSD. >> I'm trying to hook rip_input and extract the fields in IP header. I just >> tried to print the ip_len. >> This is the code, but its not getting printed. >> > > what IS getting printed? > > > Please help me... >> --------------------------------- >> >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> >> #include >> #include >> #include >> #include >> #include >> >> >> extern struct protosw inetsw[]; >> pr_input_t rip_input_hook; >> >> void rip_input_hook(struct mbuf *m, int off) >> { >> struct ip *icp; >> int hlen=off; >> int l; >> //m->m_len-=hlen; >> //m->m_data+=hlen; >> >> icp=mtod(m, struct ip *); >> l=icp->ip_len; >> >> //m->m_len+=hlen; >> //m->m_data-=hlen; >> uprintf("%d.\n",l); >> } >> >> static int >> load(struct module *module, int cmd, void *arg) >> { >> int error = 0; >> switch (cmd) { >> case MOD_LOAD: >> inetsw[ip_protox[IPPROTO_RAW]].pr_input = rip_input_hook; >> break; >> case MOD_UNLOAD: >> inetsw[ip_protox[IPPROTO_RAW]].pr_input = rip_input; >> break; >> default: >> error = EOPNOTSUPP; >> break; >> } >> return (error); >> } >> static moduledata_t rip_input_hook_mod = { >> "rip_input_hook", load, NULL}; >> >> DECLARE_MODULE(rip_input_hook,rip_input_hook_mod,SI_SUB_DRIVERS,SI_ORDER_MIDDLE); >> >> >> > -- With regards Arun Anirudhan MTech Student, NIT Calicut 9495983679 From julian at elischer.org Thu Oct 22 18:03:51 2009 From: julian at elischer.org (Julian Elischer) Date: Thu Oct 22 18:03:58 2009 Subject: rip_input In-Reply-To: References: Message-ID: <4AE09C03.6050201@elischer.org> Arun Anirudhan wrote: > Hello > I have just started programming in Kernel Level in FreeBSD. > I'm trying to hook rip_input and extract the fields in IP header. I just > tried to print the ip_len. > This is the code, but its not getting printed. what IS getting printed? > Please help me... > --------------------------------- > > #include > #include > #include > #include > #include > #include > #include > > #include > #include > #include > #include > #include > > > extern struct protosw inetsw[]; > pr_input_t rip_input_hook; > > void rip_input_hook(struct mbuf *m, int off) > { > struct ip *icp; > int hlen=off; > int l; > //m->m_len-=hlen; > //m->m_data+=hlen; > > icp=mtod(m, struct ip *); > l=icp->ip_len; > > //m->m_len+=hlen; > //m->m_data-=hlen; > uprintf("%d.\n",l); > } > > static int > load(struct module *module, int cmd, void *arg) > { > int error = 0; > switch (cmd) { > case MOD_LOAD: > inetsw[ip_protox[IPPROTO_RAW]].pr_input = rip_input_hook; > break; > case MOD_UNLOAD: > inetsw[ip_protox[IPPROTO_RAW]].pr_input = rip_input; > break; > default: > error = EOPNOTSUPP; > break; > } > return (error); > } > static moduledata_t rip_input_hook_mod = { > "rip_input_hook", load, NULL}; > DECLARE_MODULE(rip_input_hook,rip_input_hook_mod,SI_SUB_DRIVERS,SI_ORDER_MIDDLE); > > From julian at elischer.org Thu Oct 22 18:32:20 2009 From: julian at elischer.org (Julian Elischer) Date: Thu Oct 22 18:32:27 2009 Subject: rip_input In-Reply-To: References: <4AE09C03.6050201@elischer.org> Message-ID: <4AE0A533.1010802@elischer.org> Arun Anirudhan wrote: > When I make > void rip_input_hook(struct mbuf *m, int off) > to > void rip_input_hook(struct mbuf *m) its showing error! the correct current definition is in sys/protosw.h 66 /* USE THESE FOR YOUR PROTOTYPES ! */ 67 typedef void pr_input_t (struct mbuf *, int); <------------- ^^^^^^^^^^^ you should use the typedef too. 68 typedef int pr_input6_t (struct mbuf **, int*, int); /* XXX FIX THIS */ 69 typedef int pr_output_t (struct mbuf *, struct socket *); 70 typedef void pr_ctlinput_t (int, struct sockaddr *, void *); 71 typedef int pr_ctloutput_t (struct socket *, struct sockopt *); 72 typedef void pr_init_t (void); 73 typedef void pr_destroy_t (void); 74 typedef void pr_fasttimo_t (void); 75 typedef void pr_slowtimo_t (void); 76 typedef void pr_drain_t (void); 77 78 struct protosw { 79 short pr_type; /* socket type used for */ 80 struct domain *pr_domain; /* domain protocol a member of */ 81 short pr_protocol; /* protocol number */ 82 short pr_flags; /* see below */ 83 /* protocol-protocol hooks */ 84 pr_input_t *pr_input; /* input to protocol (from below) */ 85 pr_output_t *pr_output; /* output to protocol (from above) */ 86 pr_ctlinput_t *pr_ctlinput; /* control input (from below) */ 87 pr_ctloutput_t *pr_ctloutput; /* control output (from above) */ 88 /* utility hooks */ 89 pr_init_t *pr_init; 90 pr_destroy_t *pr_destroy; 91 pr_fasttimo_t *pr_fasttimo; /* fast timeout (200ms) */ 92 pr_slowtimo_t *pr_slowtimo; /* slow timeout (500ms) */ 93 pr_drain_t *pr_drain; /* flush any excess space possible */ 94 95 struct pr_usrreqs *pr_usrreqs; /* user-protocol hook */ 96 }; From mav at FreeBSD.org Thu Oct 22 19:28:06 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Oct 22 19:28:13 2009 Subject: problem with pptp, using mpd In-Reply-To: <1256210582.00175808.1256199002@10.7.7.3> References: <1256210582.00175808.1256199002@10.7.7.3> Message-ID: <4AE0B243.9000700@FreeBSD.org> Mathieu L. wrote: > I am having trouble using mpd, I want to connect to a vpn with pptp > (vpn service provided by relakks.com). > > Here is my configuration: > > mpd.conf: > ######################### > > default: > load relakks > > relakks: > create bundle static B1 > set iface route default > set ipcp ranges 0.0.0.0/0 0.0.0.0/0 > # Enable Microsoft Point-to-Point encryption (MPPE) > set bundle enable compression > set ccp yes mppc > set mppc yes e128 > set bundle enable crypt-reqd > set mppc yes stateless > > create link static L1 pptp > set link action bundle B1 > # Enable both sides to authenticat each other with CHAP > set auth disable internal > set auth authname "lejatorn" > set auth password "XXXXXXXX" > set link no pap > set link no eap > set link yes chap > set link mtu 1460 > set link keep-alive 10 75 > set link max-redial 0 > # Configure PPTP and open link > set pptp peer pptp.relakks.com > set pptp disable windowing > set link enable incoming > open > [L1] LCP: auth: peer wants CHAP, I want CHAP You are trying to authorize server. :) > It seems that the authentication is failing but I don't know why as > the login and password are correct (I tested them with pptp/pon on > Debian, it worked fine). One thing that puzzles me is the > [L1] Name: "localhost" > line, as if "localhost" was used as a login or something... > > Can anyone help please? As I have replied on forum, replace set link yes chap with set link accept chap -- Alexander Motin From ml at netfence.it Fri Oct 23 08:55:48 2009 From: ml at netfence.it (Andrea Venturoli) Date: Fri Oct 23 08:55:54 2009 Subject: Wi-Fi bridge interferes with CARP Message-ID: <4AE16F90.4010405@netfence.it> Hello. I'm curios about something which happened during a test in one of my networks. Two FreeBSD 6.3 boxes (one i386, one amd64) share some IP through CARP. Now, as soon as I plugged a wi-fi bridging access point on the net (which took it's IP from DHCP only for management), I started to see this in the i386 box's logs: Oct 22 09:49:04 xxxxx kernel: arp_rtrequest: bad gateway 192.168.101.10 (!AF_LINK) Oct 22 09:49:04 xxxxx kernel: carp0: MASTER -> BACKUP (more frequent advertisement received) Oct 22 09:49:07 xxxxx kernel: arp_rtrequest: bad gateway 192.168.101.10 (!AF_LINK) Oct 22 09:49:07 xxxxx kernel: carp0: MASTER -> BACKUP (more frequent advertisement received) ... and so on every 3 seconds. The above IP is the one the two machines are sharing on the local network. Nothing like that appeared on the amd64 box. Only one Windows machine was (sometimes) using the access point. Did anyone experience such a thing? Any clue? bye & Thanks av. From c.r.n.a at wanadoo.fr Fri Oct 23 18:31:31 2009 From: c.r.n.a at wanadoo.fr (Nicolas) Date: Fri Oct 23 18:31:37 2009 Subject: Intel WiFi 5100/5300 Message-ID: <4AE1E8AB.4090003@wanadoo.fr> Hi Bernhard, I'm trying to use your driver but i have a problem: iwn0: mem 0xde000000-0xde001fff irq 16 at device 0.0 on pci2 iwn0: MIMO 1T2R, MoW, address 00:21:6b:2b:78:04 iwn0: [ITHREAD] iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11na MCS: 15Mbps 30Mbps 45Mbps 60Mbps 90Mbps 120Mbps 135Mbps 150Mbps 30Mbps 60Mbps 90Mbps 120Mbps 180Mbps 240Mbps 270Mbps 300Mbps iwn0: 11ng MCS: 15Mbps 30Mbps 45Mbps 60Mbps 90Mbps 120Mbps 135Mbps 150Mbps 30Mbps 60Mbps 90Mbps 120Mbps 180Mbps 240Mbps 270Mbps 300Mbps wlan0: Ethernet address: 00:21:6b:2b:78:04 iwn0: iwn_init_locked: radio is disabled by hardware switch I load iwnfw.ko before if_iwn.ko. But i have all time the message: iwn0: iwn_init_locked: radio is disabled by hardware switch But when i press the button nothing change, no options in the bios too. Have you an idea where the problem come from ? Thanks in adavance, Nicolas. From bschmidt at techwires.net Fri Oct 23 22:02:16 2009 From: bschmidt at techwires.net (Bernhard Schmidt) Date: Fri Oct 23 22:02:22 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <4AE1E8AB.4090003@wanadoo.fr> References: <4AE1E8AB.4090003@wanadoo.fr> Message-ID: <200910240002.12111.bschmidt@techwires.net> On Friday 23 October 2009 19:32:27 Nicolas wrote: > Hi Bernhard, > > I'm trying to use your driver but i have a problem: > > iwn0: mem 0xde000000-0xde001fff irq 16 at > device 0.0 on pci2 > iwn0: MIMO 1T2R, MoW, address 00:21:6b:2b:78:04 > iwn0: [ITHREAD] > iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps > iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps > 24Mbps 36Mbps 48Mbps 54Mbps > iwn0: 11na MCS: 15Mbps 30Mbps 45Mbps 60Mbps 90Mbps 120Mbps 135Mbps > 150Mbps 30Mbps 60Mbps 90Mbps 120Mbps 180Mbps 240Mbps 270Mbps 300Mbps > iwn0: 11ng MCS: 15Mbps 30Mbps 45Mbps 60Mbps 90Mbps 120Mbps 135Mbps > 150Mbps 30Mbps 60Mbps 90Mbps 120Mbps 180Mbps 240Mbps 270Mbps 300Mbps > wlan0: Ethernet address: 00:21:6b:2b:78:04 > iwn0: iwn_init_locked: radio is disabled by hardware switch > > I load iwnfw.ko before if_iwn.ko. > But i have all time the message: > iwn0: iwn_init_locked: radio is disabled by hardware switch > > But when i press the button nothing change, no options in the bios too. > Have you an idea where the problem come from ? > > Thanks in adavance, > Nicolas. I have no clue.. Do you have any status indication for the button, LED or something? Try press it a few times and kldunload/kldload if_iwn again. -- Bernhard From rpaulo at gmail.com Fri Oct 23 22:08:27 2009 From: rpaulo at gmail.com (Rui Paulo) Date: Fri Oct 23 22:08:35 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <200910202247.45866.bschmidt@techwires.net> References: <20091009170839.142800@gmx.net> <200910150815.58174.bschmidt@techwires.net> <200910181627.38060.bschmidt@techwires.net> <200910202247.45866.bschmidt@techwires.net> Message-ID: <3F27A279-6347-456B-A9B6-7CE847DD1A49@gmail.com> On 20 Oct 2009, at 21:47, Bernhard Schmidt wrote: > On Sunday 18 October 2009 16:27:37 Bernhard Schmidt wrote: >> On Thursday 15 October 2009 08:15:57 Bernhard Schmidt wrote: >>> .. anyways, I'll post updates on sunday. >> >> Here we go. > > Update: > * All reported issues should now be fixed, please verify. > * WPA does work. > > Still open: > * Test reports welcome, especially with 4965, 5150, 5300 and 5350. > > At this point, if no issue come up, the driver has the same > functionality as > the in tree one. > > http://techwires.net/~bschmidt/patches/freebsd/iwn/sys/ > or > http://techwires.net/~bschmidt/patches/freebsd/iwn/iwn-20091020.tar.gz This is now committed to HEAD. Thanks! -- Rui Paulo From bschmidt at techwires.net Fri Oct 23 22:15:01 2009 From: bschmidt at techwires.net (Bernhard Schmidt) Date: Fri Oct 23 22:15:07 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <4ad871310910211751t31b17133kf994728b2cbf2b39@mail.gmail.com> References: <20091009170839.142800@gmx.net> <4ad871310910211751t31b17133kf994728b2cbf2b39@mail.gmail.com> Message-ID: <200910240014.58690.bschmidt@techwires.net> Hi, Update: * iwnfw has now been split into individual modules so autoloading of firmware module(s) does work again. * Changes have been made to RUN -> AUTH transition, this should fix the issue reported by Glen and others. * Brandon reported issues in iwn_cmd() with large commands, those have been fixed to. * DEAUTH is now handled correctly. http://techwires.net/~bschmidt/patches/freebsd/iwn/iwn-20091024.tar.gz or http://techwires.net/~bschmidt/patches/freebsd/iwn/sys/ -- Bernhard From bschmidt at techwires.net Fri Oct 23 22:21:03 2009 From: bschmidt at techwires.net (Bernhard Schmidt) Date: Fri Oct 23 22:21:11 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <3F27A279-6347-456B-A9B6-7CE847DD1A49@gmail.com> References: <20091009170839.142800@gmx.net> <200910202247.45866.bschmidt@techwires.net> <3F27A279-6347-456B-A9B6-7CE847DD1A49@gmail.com> Message-ID: <200910240021.00403.bschmidt@techwires.net> On Saturday 24 October 2009 00:08:24 Rui Paulo wrote: > On 20 Oct 2009, at 21:47, Bernhard Schmidt wrote: > > On Sunday 18 October 2009 16:27:37 Bernhard Schmidt wrote: > >> On Thursday 15 October 2009 08:15:57 Bernhard Schmidt wrote: > >>> .. anyways, I'll post updates on sunday. > >> > >> Here we go. > > > > Update: > > * All reported issues should now be fixed, please verify. > > * WPA does work. > > > > Still open: > > * Test reports welcome, especially with 4965, 5150, 5300 and 5350. > > > > At this point, if no issue come up, the driver has the same > > functionality as > > the in tree one. > > > > http://techwires.net/~bschmidt/patches/freebsd/iwn/sys/ > > or > > http://techwires.net/~bschmidt/patches/freebsd/iwn/iwn-20091020.tar.gz > > This is now committed to HEAD. > > Thanks! A few minutes to early, there's been an update. Sorry for that. -- Bernhard From rpaulo at gmail.com Fri Oct 23 22:26:05 2009 From: rpaulo at gmail.com (Rui Paulo) Date: Fri Oct 23 22:26:12 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <200910240021.00403.bschmidt@techwires.net> References: <20091009170839.142800@gmx.net> <200910202247.45866.bschmidt@techwires.net> <3F27A279-6347-456B-A9B6-7CE847DD1A49@gmail.com> <200910240021.00403.bschmidt@techwires.net> Message-ID: <092CAA9E-08B2-46B5-87E1-37A993631982@gmail.com> On 23 Oct 2009, at 23:21, Bernhard Schmidt wrote: > On Saturday 24 October 2009 00:08:24 Rui Paulo wrote: >> On 20 Oct 2009, at 21:47, Bernhard Schmidt wrote: >>> On Sunday 18 October 2009 16:27:37 Bernhard Schmidt wrote: >>>> On Thursday 15 October 2009 08:15:57 Bernhard Schmidt wrote: >>>>> .. anyways, I'll post updates on sunday. >>>> >>>> Here we go. >>> >>> Update: >>> * All reported issues should now be fixed, please verify. >>> * WPA does work. >>> >>> Still open: >>> * Test reports welcome, especially with 4965, 5150, 5300 and 5350. >>> >>> At this point, if no issue come up, the driver has the same >>> functionality as >>> the in tree one. >>> >>> http://techwires.net/~bschmidt/patches/freebsd/iwn/sys/ >>> or >>> http://techwires.net/~bschmidt/patches/freebsd/iwn/iwn-20091020.tar.gz >> >> This is now committed to HEAD. >> >> Thanks! > > A few minutes to early, there's been an update. Sorry for that. Ok, please send all the updates as the output of svn diff. Thanks, -- Rui Paulo From kalin at el.net Sat Oct 24 04:13:25 2009 From: kalin at el.net (kalin m) Date: Sat Oct 24 04:13:33 2009 Subject: Marvell 88E8057 Message-ID: <4AE2780F.4080600@el.net> hi all.. does anybody here know if freebsd has a driver for Marvell 88E8057 nic chip? according to the kernel list of drivers (7.2) marvell chips are driven by the msk driver. but it doesn't show up in pciconf, dmesg or sysinstall.... strangely enough 88E8057 is not in the list in man msk. although 88E8056 and 88E8058 are. is this just bad luck?! thanks... From emss at free.fr Sat Oct 24 08:35:54 2009 From: emss at free.fr (Eric Masson) Date: Sat Oct 24 08:36:00 2009 Subject: IPSec, nat on enc device In-Reply-To: <20091020174351.T5956@maildrop.int.zabbadoz.net> (Bjoern A. Zeeb's message of "Tue, 20 Oct 2009 18:00:01 +0000 (UTC)") References: <861vkzlula.fsf@srvbsdnanssv.interne.kisoft-services.com> <9a542da30910190707q7eb173d9xf9085d220a213db1@mail.gmail.com> <86eiozjt6p.fsf@srvbsdnanssv.interne.kisoft-services.com> <20091019200549.GA9766@zeninc.net> <864opuk0e6.fsf@srvbsdnanssv.interne.kisoft-services.com> <20091020174351.T5956@maildrop.int.zabbadoz.net> Message-ID: <86tyxp6vfh.fsf@srvbsdnanssv.interne.kisoft-services.com> "Bjoern A. Zeeb" writes: Hi Bjoern, > What I said before and will repeat is that if you want to use NAT and > VPN you want to do inside NAT (addmittingly handling the local machine > is a different story). I have done that years ago with ipfw. Then your > SA works on the NAT IP. I used it to avoid formerly RFC1918 address > collisions by NATing to an unrouted public IP for just the VPNs. > THe NAT IP will not be bound to any interface at all. Ok, I've never used ipfw so shot in the dark. If I had to nat 192.168.85.0/24 to 10.0.0.1 to access 192.168.201.0/24, I would have to setup the following : ipfw add divert natd all from 192.168.85.0/24 to 192.168.201.0/24 in natd -alias_address 10.0.0.1 setkey -c << EOD spdadd 10.0.0.1/32 192.168.201.0/24 any -P out ipsec esp/tunnel/mygw-theirgw/require ; spdadd 192.168.201.0/24 10.0.0.1/32 any -P in ipsec esp/tunnel/theirgw-mygw/require ; EOD Does it seem reasonable or do I miss something ? > There is a reason major vendors have been doing inside and outside NAT > for ages now. That pf cannot do that is bad and a design problem there. Ok, thanks for you explanations. Regards -- Salut, Je ne re?oit plus de messages de la mailing-list des nordistes. -+- SG in: GNU - Un ch'ti coup d'fufe pour la route ? -+- From c.r.n.a at wanadoo.fr Sat Oct 24 09:54:44 2009 From: c.r.n.a at wanadoo.fr (Nicolas) Date: Sat Oct 24 09:54:50 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <200910240002.12111.bschmidt@techwires.net> References: <4AE1E8AB.4090003@wanadoo.fr> <200910240002.12111.bschmidt@techwires.net> Message-ID: <4AE2CE31.7080809@wanadoo.fr> Hi Bernhard, Thanks for your response, Yes i have a status indicator, the led for the wifi is always orange, i think if it's work that the led become white. I try to load/unload a few times but nothing changes, always the same message ! Another idea ? Nicolas. > > I have no clue.. Do you have any status indication for the button, LED or > something? Try press it a few times and kldunload/kldload if_iwn again From rpaulo at FreeBSD.org Sat Oct 24 10:50:23 2009 From: rpaulo at FreeBSD.org (rpaulo@FreeBSD.org) Date: Sat Oct 24 10:50:29 2009 Subject: kern/132625: [iwn] iwn drivers don't support setting country Message-ID: <200910241050.n9OAoMQg033986@freefall.freebsd.org> Synopsis: [iwn] iwn drivers don't support setting country State-Changed-From-To: open->feedback State-Changed-By: rpaulo State-Changed-When: Sat Oct 24 10:49:46 UTC 2009 State-Changed-Why: Please try the iwn driver in FreeBSD HEAD. Responsible-Changed-From-To: freebsd-net->rpaulo Responsible-Changed-By: rpaulo Responsible-Changed-When: Sat Oct 24 10:49:46 UTC 2009 Responsible-Changed-Why: Please try the iwn driver in FreeBSD HEAD. http://www.freebsd.org/cgi/query-pr.cgi?pr=132625 From sfourman at gmail.com Sat Oct 24 19:41:40 2009 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Sat Oct 24 19:41:46 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <3F27A279-6347-456B-A9B6-7CE847DD1A49@gmail.com> References: <20091009170839.142800@gmx.net> <200910150815.58174.bschmidt@techwires.net> <200910181627.38060.bschmidt@techwires.net> <200910202247.45866.bschmidt@techwires.net> <3F27A279-6347-456B-A9B6-7CE847DD1A49@gmail.com> Message-ID: <11167f520910241241o6a1ada3cmf076add6374a1add@mail.gmail.com> On Fri, Oct 23, 2009 at 5:08 PM, Rui Paulo wrote: > On 20 Oct 2009, at 21:47, Bernhard Schmidt wrote: > >> On Sunday 18 October 2009 16:27:37 Bernhard Schmidt wrote: >>> >>> On Thursday 15 October 2009 08:15:57 Bernhard Schmidt wrote: >>>> >>>> .. anyways, I'll post updates on ?sunday. >>> >>> Here we go. >> >> Update: >> * All reported issues should now be fixed, please verify. >> * WPA does work. >> >> Still open: >> * Test reports welcome, especially with 4965, 5150, 5300 and 5350. >> >> At this point, if no issue come up, the driver has the same functionality >> as >> the in tree one. >> >> http://techwires.net/~bschmidt/patches/freebsd/iwn/sys/ >> or >> http://techwires.net/~bschmidt/patches/freebsd/iwn/iwn-20091020.tar.gz > > This is now committed to HEAD. Just wanted to make everyone aware that OpenBSD just 1 hour ago commited a bunch of changes to their iwn driver. maybe some of it is useful for FreeBSD as well? Log message: huge diff introducing many of the recent changes made by intel to iwlwifi: - ICT interrupts for >=5000 series (avoids reading IWN_INT which is slow) - support v2 firmware header (including build number) - switch to v2 firmware api (requires a firmware package upgrade) - initial support for 1000 series and initial bits for upcoming 6000 series (untested as hardware is not available to the general public) - many bug fixes, including workarounds for hardware bugs make sure to update your iwn-firmware package to iwn-firmware-5.2. Sam Fourman Jr. Fourman Networks From pyunyh at gmail.com Sat Oct 24 21:46:43 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sat Oct 24 21:46:50 2009 Subject: Marvell 88E8057 In-Reply-To: <4AE2780F.4080600@el.net> References: <4AE2780F.4080600@el.net> Message-ID: <20091024214640.GE6050@michelle.cdnetworks.com> On Fri, Oct 23, 2009 at 11:44:15PM -0400, kalin m wrote: > > hi all.. > > does anybody here know if freebsd has a driver for Marvell 88E8057 nic chip? > > according to the kernel list of drivers (7.2) marvell chips are driven > by the msk driver. but it doesn't show up in pciconf, dmesg or > sysinstall.... > strangely enough 88E8057 is not in the list in man msk. although 88E8056 > and 88E8058 are. is this just bad luck?! > I think 88E8057(Yukon Ultra 2) is the latest chipset from Marvell and no one ever expressed his/her willingness to try experiment patch. I guess msk(4) in HEAD has all required features to support 88E8057. Would you try attached patch? The patch was generated against HEAD. If you have to use 7.2-RELEASE copy the following files from HEAD and apply attached patch. /usr/src/sys/dev/msk/if_msk.c /usr/src/sys/dev/msk/if_mskreg.h /usr/src/sys/dev/mii/miidevs /usr/src/sys/dev/mii/e1000phy.c /usr/src/sys/dev/mii/e1000phyreg.c -------------- next part -------------- A non-text attachment was scrubbed... Name: msk.88E8057.diff Type: text/x-diff Size: 2119 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20091024/8013123e/msk.88E8057.bin From pyunyh at gmail.com Sat Oct 24 21:52:21 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sat Oct 24 21:52:28 2009 Subject: Marvell 88E8057 In-Reply-To: <20091024214640.GE6050@michelle.cdnetworks.com> References: <4AE2780F.4080600@el.net> <20091024214640.GE6050@michelle.cdnetworks.com> Message-ID: <20091024215219.GF6050@michelle.cdnetworks.com> On Sat, Oct 24, 2009 at 02:46:40PM -0700, Pyun YongHyeon wrote: > On Fri, Oct 23, 2009 at 11:44:15PM -0400, kalin m wrote: > > > > hi all.. > > > > does anybody here know if freebsd has a driver for Marvell 88E8057 nic chip? > > > > according to the kernel list of drivers (7.2) marvell chips are driven > > by the msk driver. but it doesn't show up in pciconf, dmesg or > > sysinstall.... > > strangely enough 88E8057 is not in the list in man msk. although 88E8056 > > and 88E8058 are. is this just bad luck?! > > > > I think 88E8057(Yukon Ultra 2) is the latest chipset from Marvell > and no one ever expressed his/her willingness to try experiment > patch. I guess msk(4) in HEAD has all required features to support > 88E8057. Would you try attached patch? > > The patch was generated against HEAD. If you have to use 7.2-RELEASE > copy the following files from HEAD and apply attached patch. > > /usr/src/sys/dev/msk/if_msk.c > /usr/src/sys/dev/msk/if_mskreg.h > /usr/src/sys/dev/mii/miidevs > /usr/src/sys/dev/mii/e1000phy.c > /usr/src/sys/dev/mii/e1000phyreg.c ^^^^^^^^^^^^^^ It should be read e1000phyreg.h From kalin at el.net Sat Oct 24 23:06:07 2009 From: kalin at el.net (kalin m) Date: Sat Oct 24 23:06:14 2009 Subject: Marvell 88E8057 In-Reply-To: <20091024215219.GF6050@michelle.cdnetworks.com> References: <4AE2780F.4080600@el.net> <20091024214640.GE6050@michelle.cdnetworks.com> <20091024215219.GF6050@michelle.cdnetworks.com> Message-ID: <4AE387C8.7020703@el.net> Pyun YongHyeon wrote: > On Sat, Oct 24, 2009 at 02:46:40PM -0700, Pyun YongHyeon wrote: > >> On Fri, Oct 23, 2009 at 11:44:15PM -0400, kalin m wrote: >> >>> hi all.. >>> >>> does anybody here know if freebsd has a driver for Marvell 88E8057 nic chip? >>> >>> according to the kernel list of drivers (7.2) marvell chips are driven >>> by the msk driver. but it doesn't show up in pciconf, dmesg or >>> sysinstall.... >>> strangely enough 88E8057 is not in the list in man msk. although 88E8056 >>> and 88E8058 are. is this just bad luck?! >>> >>> >> I think 88E8057(Yukon Ultra 2) is the latest chipset from Marvell >> and no one ever expressed his/her willingness to try experiment >> patch. I guess msk(4) in HEAD has all required features to support >> 88E8057. Would you try attached patch? >> >> The patch was generated against HEAD. If you have to use 7.2-RELEASE >> copy the following files from HEAD and apply attached patch. >> >> /usr/src/sys/dev/msk/if_msk.c >> /usr/src/sys/dev/msk/if_mskreg.h >> /usr/src/sys/dev/mii/miidevs >> /usr/src/sys/dev/mii/e1000phy.c >> /usr/src/sys/dev/mii/e1000phyreg.c >> > ^^^^^^^^^^^^^^ > It should be read e1000phyreg.h > i certainly would try the patch. i have not gotten the email with the attachment. and it would probably happened on monday. the machine is in my office. but i'm interested to try it... thanks.... From bschmidt at techwires.net Sun Oct 25 09:24:10 2009 From: bschmidt at techwires.net (Bernhard Schmidt) Date: Sun Oct 25 09:24:17 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <11167f520910241241o6a1ada3cmf076add6374a1add@mail.gmail.com> References: <20091009170839.142800@gmx.net> <3F27A279-6347-456B-A9B6-7CE847DD1A49@gmail.com> <11167f520910241241o6a1ada3cmf076add6374a1add@mail.gmail.com> Message-ID: <200910251024.06856.bschmidt@techwires.net> On Saturday 24 October 2009 21:41:39 Sam Fourman Jr. wrote: > Just wanted to make everyone aware that OpenBSD just 1 hour ago commited > a bunch of changes to their iwn driver. maybe some of it is useful for > FreeBSD as well? > > Log message: > huge diff introducing many of the recent changes made by intel to iwlwifi: > - ICT interrupts for >=5000 series (avoids reading IWN_INT which is slow) > - support v2 firmware header (including build number) > - switch to v2 firmware api (requires a firmware package upgrade) > - initial support for 1000 series and initial bits for upcoming 6000 > series (untested as hardware is not available to the general public) > - many bug fixes, including workarounds for hardware bugs > > make sure to update your iwn-firmware package to iwn-firmware-5.2. Definitely, I'll look into that. -- Bernhard From atkin901 at yahoo.com Sun Oct 25 20:00:12 2009 From: atkin901 at yahoo.com (Mark Atkinson) Date: Sun Oct 25 20:00:18 2009 Subject: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Message-ID: <200910252000.n9PK0BGp025546@freefall.freebsd.org> The following reply was made to PR kern/124127; it has been noted by GNATS. From: Mark Atkinson To: freebsd prs Cc: Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Date: Sun, 25 Oct 2009 12:55:38 -0700 (PDT) After a week on a Oct 19th 2009 built kernel, I got hit with the watchdog again, so I applied the patch. The msk interface was non functional (came up but was unable to pass traffic) after applying the patch, so I booted back to the unpatched kernel. Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired); From seesaravanan at yahoo.co.in Mon Oct 26 09:43:09 2009 From: seesaravanan at yahoo.co.in (saravana perumal) Date: Mon Oct 26 09:43:15 2009 Subject: Invitation to connect on LinkedIn Message-ID: <1091669987.2430605.1256548507494.JavaMail.app@ech3-cdn06.prod> LinkedIn ------------ saravana perumal requested to add you as a connection on LinkedIn: ------------------------------------------ Scott, I'd like to add you to my professional network on LinkedIn. - saravana Accept invitation from saravana perumal http://www.linkedin.com/e/PLgN6ynStv_BKk9UWJP96hnStv_BKkDo9Z0f/blk/I1533505122_2/pmpxnSRJrSdvj4R5fnhv9ClRsDgZp6lQs6lzoQ5AomZIpn8_cBYOcz4Rc3kPcPkNiiZds7x7rnhJmyYUdz0PcPAVcjwLrCBxbOYWrSlI/EML_comm_afe/ View invitation from saravana perumal http://www.linkedin.com/e/PLgN6ynStv_BKk9UWJP96hnStv_BKkDo9Z0f/blk/I1533505122_2/39vcz8Ndj0RcPcRckALqnpPbOYWrSlI/svi/ ------------------------------------------ DID YOU KNOW that LinkedIn can find the answers to your most difficult questions? Post those vexing questions on LinkedIn Answers to tap into the knowledge of the world's foremost business experts: http://www.linkedin.com/e/ask/inv-23/ ------ (c) 2009, LinkedIn Corporation From bugmaster at FreeBSD.org Mon Oct 26 11:07:04 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 26 11:09:22 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200910261107.n9QB737U043833@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/139761 net [bce] bce driver on IBM HS22 [No PHY found on Child MI o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139559 net [tun] several tun(4) interfaces can be created with sa o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139162 net [fwip] [panic] 8.0-RC1 panics if using IP over firewir o kern/139145 net [ip6] IPv6 blackhole / reject routes broken o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139113 net [arp] removing IP alias doesn't delete permanent arp e o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138999 net [libc] lighttpd/php-cgi with freebsd sendfile(2) enabl o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o kern/138694 net [bge] FreeBSD 6.3 release does not recognize Broadcom o amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138676 net [route] after buildworld not work local routes [regres f kern/138666 net [multicast] [panic] not working multicast through igmp o kern/138660 net [igb] igb driver troubles in 8.0-BETA4 o kern/138652 net TCP window scaling value calculated incorrectly? o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138378 net [altq] [patch] Memory leak in hfsc_class_modify() in f o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR on 8.0-BE o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/138130 net [netinet] [patch] Resource leak in LibAliasRefreshModu o kern/138046 net [tcp] tcp sockets stay in SYN_SENT even after receivin o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137795 net [sctp] [panic] mtx_lock() of destroyed mutex o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137317 net [tcp] logs full of syncache problems o kern/137292 net [ste] DFE-580TX not working properly o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136482 net [age] Attansic L1 Gigabit Ethernet recieves multicasts o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135836 net [bce] bce BCM5709 Watchdog after warm boot - ok after o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/135067 net [patch] [fib] Incorrect KASSERTs in sys/net/route.c o kern/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se o kern/134931 net [route] [fib] Route messages sent to all socket listen o kern/134658 net [bce] bce driver fails on PowerEdge m610 blade. o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134369 net [route] [ip6] IPV6 in Head broken for routing table up o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133786 net [netinet] [patch] ip_input might cause kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] [patch] if_sis short cable fix problems with Net s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 356 problems total. From freebsd at levsha.org.ua Mon Oct 26 15:53:04 2009 From: freebsd at levsha.org.ua (Mykola Dzham) Date: Mon Oct 26 15:53:11 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <200910240014.58690.bschmidt@techwires.net> References: <20091009170839.142800@gmx.net> <4ad871310910211751t31b17133kf994728b2cbf2b39@mail.gmail.com> <200910240014.58690.bschmidt@techwires.net> Message-ID: <20091026151053.GZ93554@expo.ukrweb.net> Bernhard Schmidt wrote: > Hi, > > Update: > > * iwnfw has now been split into individual modules so autoloading of firmware > module(s) does work again. > * Changes have been made to RUN -> AUTH transition, this should fix the issue > reported by Glen and others. > * Brandon reported issues in iwn_cmd() with large commands, those have been > fixed to. > * DEAUTH is now handled correctly. > > http://techwires.net/~bschmidt/patches/freebsd/iwn/iwn-20091024.tar.gz > or > http://techwires.net/~bschmidt/patches/freebsd/iwn/sys/ My 9.0-CURRENT r198465M amd64 crashes immediately after loading if_iwn Backtrace from core: (kgdb) bt #0 doadump () at pcpu.h:223 #1 0xffffffff8016e35c in db_fncall (dummy1=Variable "dummy1" is not available. ) at /usr/local/arch/src/sys/ddb/db_command.c:548 #2 0xffffffff8016e691 in db_command (last_cmdp=0xffffffff805cff60, cmd_table=Variable "cmd_table" is not available. ) at /usr/local/arch/src/sys/ddb/db_command.c:445 #3 0xffffffff8016e8e0 in db_command_loop () at /usr/local/arch/src/sys/ddb/db_command.c:498 #4 0xffffffff801708b9 in db_trap (type=Variable "type" is not available. ) at /usr/local/arch/src/sys/ddb/db_main.c:229 #5 0xffffffff80232ab5 in kdb_trap (type=12, code=0, tf=0xffffff807923ea10) at /usr/local/arch/src/sys/kern/subr_kdb.c:535 #6 0xffffffff803dad8d in trap_fatal (frame=0xffffff807923ea10, eva=Variable "eva" is not available. ) at /usr/local/arch/src/sys/amd64/amd64/trap.c:855 #7 0xffffffff803dba35 in trap (frame=0xffffff807923ea10) at /usr/local/arch/src/sys/amd64/amd64/trap.c:348 #8 0xffffffff803c13a3 in calltrap () at /usr/local/arch/src/sys/amd64/amd64/exception.S:224 #9 0xffffffff803bba81 in _bus_dmamap_sync (dmat=0xffffff011008cd00, map=Variable "map" is not available. ) at /usr/local/arch/src/sys/amd64/amd64/busdma_machdep.c:933 #10 0xffffffff80ed86ae in iwn_notif_intr () from /boot/kernel/if_iwn.ko #11 0xffffffff80ed8bf5 in iwn_intr () from /boot/kernel/if_iwn.ko #12 0xffffff0110038780 in ?? () #13 0x0000000000000000 in ?? () #14 0xffffff00312a9c00 in ?? () #15 0xffffff00312a9c48 in ?? () #16 0xffffff00312a9ca8 in ?? () #17 0xffffff807923ebd0 in ?? () #18 0xffffffff801ddbb6 in intr_event_execute_handlers (p=Variable "p" is not available. ) at /usr/local/arch/src/sys/kern/kern_intr.c:1220 Previous frame inner to this frame (corrupt stack?) (kgdb) Full crashinfo is on http://levsha.me/crash/iwn/core.20091025.txt -- LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280 From kalin at el.net Mon Oct 26 16:11:32 2009 From: kalin at el.net (kalin m) Date: Mon Oct 26 16:11:39 2009 Subject: Marvell 88E8057 In-Reply-To: <20091024215219.GF6050@michelle.cdnetworks.com> References: <4AE2780F.4080600@el.net> <20091024214640.GE6050@michelle.cdnetworks.com> <20091024215219.GF6050@michelle.cdnetworks.com> Message-ID: <4AE5C99B.2000102@el.net> Pyun YongHyeon wrote: > On Sat, Oct 24, 2009 at 02:46:40PM -0700, Pyun YongHyeon wrote: > >> On Fri, Oct 23, 2009 at 11:44:15PM -0400, kalin m wrote: >> >>> hi all.. >>> >>> does anybody here know if freebsd has a driver for Marvell 88E8057 nic chip? >>> >>> according to the kernel list of drivers (7.2) marvell chips are driven >>> by the msk driver. but it doesn't show up in pciconf, dmesg or >>> sysinstall.... >>> strangely enough 88E8057 is not in the list in man msk. although 88E8056 >>> and 88E8058 are. is this just bad luck?! >>> >>> >> I think 88E8057(Yukon Ultra 2) is the latest chipset from Marvell >> and no one ever expressed his/her willingness to try experiment >> patch. I guess msk(4) in HEAD has all required features to support >> 88E8057. Would you try attached patch? >> >> The patch was generated against HEAD. If you have to use 7.2-RELEASE >> copy the following files from HEAD and apply attached patch. >> >> /usr/src/sys/dev/msk/if_msk.c >> /usr/src/sys/dev/msk/if_mskreg.h >> /usr/src/sys/dev/mii/miidevs >> /usr/src/sys/dev/mii/e1000phy.c >> /usr/src/sys/dev/mii/e1000phyreg.c >> > ^^^^^^^^^^^^^^ > It should be read e1000phyreg.h > hi there Pyun YongHyeon... i stillhave not gotten you previous email with the attached patch. can you resend please? thanks..... From fbsdlists at gmail.com Mon Oct 26 17:45:52 2009 From: fbsdlists at gmail.com (Bob Johnson) Date: Mon Oct 26 17:46:25 2009 Subject: Marvell 88E8057 In-Reply-To: <4AE2780F.4080600@el.net> References: <4AE2780F.4080600@el.net> Message-ID: <54db43990910261015k239933e0l3528d463d8cf7f50@mail.gmail.com> On 10/23/09, kalin m wrote: > > hi all.. > > does anybody here know if freebsd has a driver for Marvell 88E8057 nic chip? > Marvell provides FreeBSD drivers. If you don't have a philosophical objection to using a manufacturer's binary driver, you might find what you need at their website. http://www.marvell.com/drivers/search.do I think they provide one FreeBSD driver for all of their chipsets. Don't know if it supports the 88E8057. -- -- Bob Johnson fbsdlists@gmail.com From kalin at el.net Mon Oct 26 17:51:24 2009 From: kalin at el.net (kalin m) Date: Mon Oct 26 17:51:32 2009 Subject: Marvell 88E8057 In-Reply-To: <54db43990910261015k239933e0l3528d463d8cf7f50@mail.gmail.com> References: <4AE2780F.4080600@el.net> <54db43990910261015k239933e0l3528d463d8cf7f50@mail.gmail.com> Message-ID: <4AE5E104.2010302@el.net> Bob Johnson wrote: > On 10/23/09, kalin m wrote: > >> hi all.. >> >> does anybody here know if freebsd has a driver for Marvell 88E8057 nic chip? >> >> > > Marvell provides FreeBSD drivers. If you don't have a philosophical > objection to using a manufacturer's binary driver, you might find what > you need at their website. > > http://www.marvell.com/drivers/search.do > > I think they provide one FreeBSD driver for all of their chipsets. > Don't know if it supports the 88E8057. > i do. i found that page last thursday. and a saw a few freebsd drivers. but not for 88E8057. thanks thought.... From dudu at dudu.ro Mon Oct 26 20:35:02 2009 From: dudu at dudu.ro (Vlad Galu) Date: Mon Oct 26 20:35:09 2009 Subject: quagga ignoring RTM_DELETE messages? Message-ID: Hi list, sorry for the noise here. I'm experiencing a weird issue with the latest Quagga from ports, on a 8.0-RC1. It was configured to redistribute kernel routes to BGP, which it does. However, when a route is deleted, it's still announced to the BGP peer. RTM_DELETE was picked up by "route monitor"... This exact same setup used to work before upgrading to RELENG_8. Am I missing something? Thanks, Vlad From arno at heho.snv.jussieu.fr Tue Oct 27 00:01:31 2009 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Tue Oct 27 00:01:43 2009 Subject: ZFS and 'traditional' nfs-export Message-ID: Hello, I googled a bit on this question but could not find a clear answer : is there any risk/inconvenience/advantage in exporting a ZFS-fs by just putting it in /etc/exports the old way and leaving the 'sharenfs' option on the filesystem off? I'd like to replace a UFS-based server serving mostly linux-clients which work well now with a ZFS-fs, and somehow am a bit waterfearing changing the nfs?options which worked great till now. Thank you in advance, regards, Arno From tom at tomjudge.com Tue Oct 27 17:27:45 2009 From: tom at tomjudge.com (Tom Judge) Date: Tue Oct 27 17:27:59 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver Message-ID: <4AE72910.8090708@tomjudge.com> Hi, Has anyone seen these errors before: http://www.freebsd.org/cgi/query-pr.cgi?pr=135836&cat= The system is a Dell R610 and it happens on both cold and warm boots. I am about to check a second chassis, and test with 8, and will follow up after my tests. Tom From dudu at dudu.ro Tue Oct 27 18:44:43 2009 From: dudu at dudu.ro (Vlad Galu) Date: Tue Oct 27 18:44:50 2009 Subject: quagga ignoring RTM_DELETE messages? In-Reply-To: References: Message-ID: On Mon, Oct 26, 2009 at 10:34 PM, Vlad Galu wrote: > Hi list, sorry for the noise here. > > I'm experiencing a weird issue with the latest Quagga from ports, on a > 8.0-RC1. It was configured to redistribute kernel routes to BGP, which > it does. However, when a route is deleted, it's still announced to the > BGP peer. RTM_DELETE was picked up by "route monitor"... This exact > same setup used to work before upgrading to RELENG_8. Am I missing > something? > > Thanks, > Vlad > So, everybody happy with Quagga + RELENG_8? From mike at sentex.net Tue Oct 27 18:50:47 2009 From: mike at sentex.net (Mike Tancsa) Date: Tue Oct 27 18:50:55 2009 Subject: quagga ignoring RTM_DELETE messages? In-Reply-To: References: Message-ID: <200910271850.n9RIoiVD004770@lava.sentex.ca> At 02:44 PM 10/27/2009, Vlad Galu wrote: >On Mon, Oct 26, 2009 at 10:34 PM, Vlad Galu wrote: > > Hi list, sorry for the noise here. > > > > I'm experiencing a weird issue with the latest Quagga from ports, on a > > 8.0-RC1. It was configured to redistribute kernel routes to BGP, which > > it does. However, when a route is deleted, it's still announced to the > > BGP peer. RTM_DELETE was picked up by "route monitor"... This exact > > same setup used to work before upgrading to RELENG_8. Am I missing > > something? > > > > Thanks, > > Vlad > > > >So, everybody happy with Quagga + RELENG_8? I havent tried it yet. Can you post your quagga config and I will try and recreate here on my RELENG_8 test box. ---Mike >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From ler at lerctr.org Tue Oct 27 19:32:35 2009 From: ler at lerctr.org (Larry Rosenman) Date: Tue Oct 27 19:32:42 2009 Subject: ZFS and 'traditional' nfs-export In-Reply-To: References: Message-ID: <00b301ca5739$8e9b3850$abd1a8f0$@org> ZFS makes its own version of the exports file. Just do it that way, and be safe. You can pass the full set of NFS options in the sharenfs parameter.... -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Arno J. Klaassen Sent: Monday, October 26, 2009 6:46 PM To: freebsd-fs@freebsd.org Cc: freebsd-net@freebsd.org Subject: ZFS and 'traditional' nfs-export Hello, I googled a bit on this question but could not find a clear answer : is there any risk/inconvenience/advantage in exporting a ZFS-fs by just putting it in /etc/exports the old way and leaving the 'sharenfs' option on the filesystem off? I'd like to replace a UFS-based server serving mostly linux-clients which work well now with a ZFS-fs, and somehow am a bit waterfearing changing the nfs?options which worked great till now. Thank you in advance, regards, Arno _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From tom at tomjudge.com Tue Oct 27 20:12:11 2009 From: tom at tomjudge.com (Tom Judge) Date: Tue Oct 27 20:12:18 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: <4AE72910.8090708@tomjudge.com> References: <4AE72910.8090708@tomjudge.com> Message-ID: <4AE753E4.6050205@tomjudge.com> Tom Judge wrote: > Hi, > > Has anyone seen these errors before: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=135836&cat= > > The system is a Dell R610 and it happens on both cold and warm boots. > > I am about to check a second chassis, and test with 8, and will follow > up after my tests. > Here are my tests with 3 of the 13th Gen Dell chassis. http://www.tomjudge.com/index.php/FreeBSD/Dell_13th_Gen_Servers Summary: R710 is fine R410 is fine once you can get it to PXE load correctly R610 is no good at the moment. Tom From killing at multiplay.co.uk Tue Oct 27 20:41:37 2009 From: killing at multiplay.co.uk (Steven Hartland) Date: Tue Oct 27 20:41:43 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver References: <4AE72910.8090708@tomjudge.com> <4AE753E4.6050205@tomjudge.com> Message-ID: M610 is also broken due to unsupported bge revision :( Regards Steve ----- Original Message ----- From: "Tom Judge" To: Cc: ; "Xin LI" ; "David Christensen" ; ; "Stanislav Sedov" Sent: Tuesday, October 27, 2009 8:11 PM Subject: Re: bce(4) BCM5907 CTX write errors on 7.2 driver > Tom Judge wrote: >> Hi, >> >> Has anyone seen these errors before: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=135836&cat= >> >> The system is a Dell R610 and it happens on both cold and warm boots. >> >> I am about to check a second chassis, and test with 8, and will follow up after my tests. >> > > Here are my tests with 3 of the 13th Gen Dell chassis. > > http://www.tomjudge.com/index.php/FreeBSD/Dell_13th_Gen_Servers > > Summary: > > R710 is fine > R410 is fine once you can get it to PXE load correctly > > R610 is no good at the moment. > > Tom > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From dudu at dudu.ro Tue Oct 27 20:41:45 2009 From: dudu at dudu.ro (Vlad Galu) Date: Tue Oct 27 20:41:52 2009 Subject: quagga ignoring RTM_DELETE messages? In-Reply-To: <200910271850.n9RIoiVD004770@lava.sentex.ca> References: <200910271850.n9RIoiVD004770@lava.sentex.ca> Message-ID: On Tue, Oct 27, 2009 at 8:50 PM, Mike Tancsa wrote: > At 02:44 PM 10/27/2009, Vlad Galu wrote: >> >> On Mon, Oct 26, 2009 at 10:34 PM, Vlad Galu wrote: >> > Hi list, sorry for the noise here. >> > >> > I'm experiencing a weird issue with the latest Quagga from ports, on a >> > 8.0-RC1. It was configured to redistribute kernel routes to BGP, which >> > it does. However, when a route is deleted, it's still announced to the >> > BGP peer. RTM_DELETE was picked up by "route monitor"... This exact >> > same setup used to work before upgrading to RELENG_8. Am I missing >> > something? >> > >> > Thanks, >> > Vlad >> > >> >> So, everybody happy with Quagga + RELENG_8? > > I havent tried it yet. Can you post your quagga config and I will try and > recreate here on my RELENG_8 test box. > > ? ? ? ?---Mike > > >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > -------------------------------------------------------------------- > Mike Tancsa, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?tel +1 519 651 3400 > Sentex Communications, ? ? ? ? ? ? ? ? ? ? ? ? ? ?mike@sentex.net > Providing Internet since 1994 ? ? ? ? ? ? ? ? ? ?www.sentex.net > Cambridge, Ontario Canada ? ? ? ? ? ? ? ? ? ? ? ? www.sentex.net/mike > > Sure Mike, thanks! Here's the bgpd.conf: -- cut here -- router bgp bgp router-id redistribute kernel neighbor remote-as neighbor next-hop-self neighbor soft-reconfiguration inbound neighbor route-map filtru out route-map filtru permit 10 set community 5483:10000 6746:10000 additive set ip next-hop 192.168.192.168 -- and here -- A sniffer runs on this machine, watching all inbound traffic for DDoS attacks, and nullroutes the attacked IP. What it actually does is to add a static route towards the attacked IP, through 127.0.0.1, with the following flags set: RTF_UP|RTF_GATEWAY|RTF_HOST|RTF_BLACKHOLE|RTF_STATIC. Then, the static route is seen by Quagga and redistributed into BGP. After a while, the monitoring software removes the static route, and Quagga used (on 7.x) to also stop announcing it to the neighbor. For some reason, this second part doesn't happen anymore, although the static route is clearly not in the routing table anymore, and "route monitor" sees the kernel's RTM_DEL message (and so should Quagga). For the record, the same setup almost works with OpenBGPD, the only difference being that I have to replace 127.0.0.1 with another reachable (directly connected) IP when setting the static route, otherwise OpenBGPD ignores it (which I suspect is due to some internal check). OpenBGPD correctly stops exporting the static route to the BGP peer once it's removed from the routing table by the monitoring software. Thanks for looking into this! From tom at tomjudge.com Tue Oct 27 21:22:03 2009 From: tom at tomjudge.com (Tom Judge) Date: Tue Oct 27 21:22:11 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: References: <4AE72910.8090708@tomjudge.com> <4AE753E4.6050205@tomjudge.com> Message-ID: <4AE76444.7070309@tomjudge.com> Steven Hartland wrote: > M610 is also broken due to unsupported bge revision :( > Hi Steve, This seems to be a missing PHY driver for bce(4)+SerDes rather than a bge issue, see PR:kern/134658 You already refrenced this in a thread on current@ releated to an HP system. I have added this info to my page. Tom > ----- Original Message ----- From: "Tom Judge" > To: > Cc: ; "Xin LI" ; "David > Christensen" ; ; > "Stanislav Sedov" > Sent: Tuesday, October 27, 2009 8:11 PM > Subject: Re: bce(4) BCM5907 CTX write errors on 7.2 driver > > >> Tom Judge wrote: >>> Hi, >>> >>> Has anyone seen these errors before: >>> >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=135836&cat= >>> >>> The system is a Dell R610 and it happens on both cold and warm boots. >>> >>> I am about to check a second chassis, and test with 8, and will >>> follow up after my tests. >>> >> >> Here are my tests with 3 of the 13th Gen Dell chassis. >> >> http://www.tomjudge.com/index.php/FreeBSD/Dell_13th_Gen_Servers >> >> Summary: >> >> R710 is fine >> R410 is fine once you can get it to PXE load correctly >> >> R610 is no good at the moment. >> >> Tom >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. > and the person or entity to whom it is addressed. In the event of > misdirection, the recipient is prohibited from using, copying, > printing or otherwise disseminating it or any information contained in > it. > In the event of misdirection, illegible or incomplete transmission > please telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From tom at tomjudge.com Tue Oct 27 21:30:04 2009 From: tom at tomjudge.com (Tom Judge) Date: Tue Oct 27 21:30:14 2009 Subject: kern/139761: [bce] bce driver on IBM HS22 [No PHY found on Child MII bus] Message-ID: <200910272130.n9RLU4G0071513@freefall.freebsd.org> The following reply was made to PR kern/139761; it has been noted by GNATS. From: Tom Judge To: bug-followup@FreeBSD.org, sebastian.tymkow@gmail.com Cc: Subject: Re: kern/139761: [bce] bce driver on IBM HS22 [No PHY found on Child MII bus] Date: Tue, 27 Oct 2009 21:25:30 +0000 Hi, This seems to be a duplicate of: kern/136417 Tom From arno at heho.snv.jussieu.fr Tue Oct 27 21:39:33 2009 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Tue Oct 27 21:39:41 2009 Subject: ZFS and 'traditional' nfs-export In-Reply-To: <00b301ca5739$8e9b3850$abd1a8f0$@org> (Larry Rosenman's message of "Tue\, 27 Oct 2009 14\:13\:14 -0500") References: <00b301ca5739$8e9b3850$abd1a8f0$@org> Message-ID: hello, "Larry Rosenman" writes: > ZFS makes its own version of the exports file. > > Just do it that way, and be safe. > > You can pass the full set of NFS options in the sharenfs parameter.... ah ok, I see. Thanks for answering. I got fooled by the man zfs(1M) example : zfs set sharenfs='rw=@123.123.0.0/16,root=neo' tank/home This syntax does not seem to work for me (8.0RC2). Maybe an extra line could be added that one can just set the sharenfs property to exactly the same character string as in /etc/exports. Once again, merci. Arno From tom at tomjudge.com Tue Oct 27 21:40:03 2009 From: tom at tomjudge.com (Tom Judge) Date: Tue Oct 27 21:40:15 2009 Subject: kern/135836: [bce] bce BCM5709 Watchdog after warm boot - ok after cold boot Message-ID: <200910272140.n9RLe3RE081064@freefall.freebsd.org> The following reply was made to PR kern/135836; it has been noted by GNATS. From: Tom Judge To: bug-followup@FreeBSD.org, rwilliams@borderware.com Cc: Subject: Re: kern/135836: [bce] bce BCM5709 Watchdog after warm boot - ok after cold boot Date: Tue, 27 Oct 2009 21:30:51 +0000 Hi, This seems to be a duplicate of: kern/134788 Tom From tom at tomjudge.com Tue Oct 27 21:40:05 2009 From: tom at tomjudge.com (Tom Judge) Date: Tue Oct 27 21:40:16 2009 Subject: kern/134658: [bce] bce driver fails on PowerEdge m610 blade. Message-ID: <200910272140.n9RLe54x081089@freefall.freebsd.org> The following reply was made to PR kern/134658; it has been noted by GNATS. From: Tom Judge To: bug-followup@FreeBSD.org, harald_jensas@dell.com Cc: Subject: Re: kern/134658: [bce] bce driver fails on PowerEdge m610 blade. Date: Tue, 27 Oct 2009 21:32:24 +0000 Hi, This seems to be a duplicate of these 2: kern/139761 kern/136417 Tom From tom at tomjudge.com Tue Oct 27 21:56:20 2009 From: tom at tomjudge.com (Tom Judge) Date: Tue Oct 27 21:56:26 2009 Subject: bce(4) PRs - brief analysis Message-ID: <4AE76C4F.7030900@tomjudge.com> Hi, I went looking though all the PRs related to bce(4) this afternoon trying to shed some light on my R610 issue and came across the following duplicates: No SerDes PHY Support: kern/139761 kern/136417 kern/134658 - and possibly kern/118238 however this is different controller. CTX Write Errors: kern/135836 kern/134788 What is the correct way to report these duplicates? Also the follow 3 seem to be from a time when the bce driver was very buggy: kern/107850 kern/100858 kern/108542 These issues should no longer be present in 7.0+ ( I have not tested any other 6.X releases however I do have a patched 6.2 that works correctly based on changes that went into HEAD leading up to /Fri Jul 20 09:19:15 2007 UTC). Tom / From tom at tomjudge.com Tue Oct 27 22:00:14 2009 From: tom at tomjudge.com (Tom Judge) Date: Tue Oct 27 22:01:40 2009 Subject: kern/107850: [bce] bce driver link negotiation is faulty Message-ID: <200910272200.n9RM09TO097341@freefall.freebsd.org> The following reply was made to PR kern/107850; it has been noted by GNATS. From: Tom Judge To: bug-followup@FreeBSD.org, olavi@ipunplugged.com Cc: Subject: Re: kern/107850: [bce] bce driver link negotiation is faulty Date: Tue, 27 Oct 2009 21:51:05 +0000 This bug should not be present in modern releases (7.0+). Tom From tom at tomjudge.com Tue Oct 27 22:00:14 2009 From: tom at tomjudge.com (Tom Judge) Date: Tue Oct 27 22:01:41 2009 Subject: kern/108542: [bce] Huge network latencies with 6.2-RELEASE / STABLE Message-ID: <200910272200.n9RM0CXZ097372@freefall.freebsd.org> The following reply was made to PR kern/108542; it has been noted by GNATS. From: Tom Judge To: bug-followup@FreeBSD.org, remy@unix-asp.com Cc: Subject: Re: kern/108542: [bce] Huge network latencies with 6.2-RELEASE / STABLE Date: Tue, 27 Oct 2009 21:53:41 +0000 This should not be a problem in more modern releases (7.0+). Tom From davidch at broadcom.com Tue Oct 27 22:04:41 2009 From: davidch at broadcom.com (David Christensen) Date: Tue Oct 27 22:04:47 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: <4AE72910.8090708@tomjudge.com> References: <4AE72910.8090708@tomjudge.com> Message-ID: <5D267A3F22FD854F8F48B3D2B52381933A04B49180@IRVEXCHCCR01.corp.ad.broadcom.com> > Has anyone seen these errors before: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=135836&cat= > > The system is a Dell R610 and it happens on both cold and warm boots. > > I am about to check a second chassis, and test with 8, and > will follow up after my tests. Yes, I've seen these errors on a Dell r710. The problem is related to an interaction between the FreeBSD driver and the bootcode firmware on the BCM5709 controller which can cause the bootcode firmware to enable certain hardware blocks in the chip while the FreeBSD driver is attempting to reset the device. This allows RX traffic to enter the controller before the device is fully initialized. The fix is to upgrade the BCM5709 bootcode to version 5.02 or later. I'm checking if Dell has posted updated firmware which can address the problem. Dave From tom at tomjudge.com Tue Oct 27 22:11:51 2009 From: tom at tomjudge.com (Tom Judge) Date: Tue Oct 27 22:12:02 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: <5D267A3F22FD854F8F48B3D2B52381933A04B49180@IRVEXCHCCR01.corp.ad.broadcom.com> References: <4AE72910.8090708@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B49180@IRVEXCHCCR01.corp.ad.broadcom.com> Message-ID: <4AE76FF1.9010401@tomjudge.com> David Christensen wrote: >> Has anyone seen these errors before: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=135836&cat= >> >> The system is a Dell R610 and it happens on both cold and warm boots. >> >> I am about to check a second chassis, and test with 8, and >> will follow up after my tests. >> > > Yes, I've seen these errors on a Dell r710. The problem is related > to an interaction between the FreeBSD driver and the bootcode firmware > on the BCM5709 controller which can cause the bootcode firmware to > enable certain hardware blocks in the chip while the FreeBSD driver is > attempting to reset the device. This allows RX traffic to enter the > controller before the device is fully initialized. > > The fix is to upgrade the BCM5709 bootcode to version 5.02 or later. > I'm checking if Dell has posted updated firmware which can address > the problem. > > Hi David, Thanks for the rapid response. Dell have firmware 5.0.9 on their website here: http://tiny.cc/ex834 Will that work? Tom From davidch at broadcom.com Tue Oct 27 22:18:46 2009 From: davidch at broadcom.com (David Christensen) Date: Tue Oct 27 22:18:53 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: <4AE76FF1.9010401@tomjudge.com> References: <4AE72910.8090708@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B49180@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE76FF1.9010401@tomjudge.com> Message-ID: <5D267A3F22FD854F8F48B3D2B52381933A04B491AE@IRVEXCHCCR01.corp.ad.broadcom.com> > Thanks for the rapid response. > > Dell have firmware 5.0.9 on their website here: http://tiny.cc/ex834 > > Will that work? Yes, that release does include a good version of BCM5709 bootcode (v5.06). I couldn't really tell until I downloaded the file and looked at the temporary files inside. Thanks for the link. Dave From dougb at FreeBSD.org Tue Oct 27 22:29:09 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Oct 27 22:30:56 2009 Subject: Can we turn off WPI_DEBUG Message-ID: <4AE77437.4090700@FreeBSD.org> I cc'ed those who seem to have put the most/recent effort into sys/dev/wpi. Is there any objection to turning off WPI_DEBUG by default? it creates a lot of spam that the average user doesn't need. I use my 3945abg every day and haven't had any problems with it for ages so I think it's safe to say we're out of the period were debug by default is needed? Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From remodeler at alentogroup.org Tue Oct 27 22:34:37 2009 From: remodeler at alentogroup.org (remodeler) Date: Tue Oct 27 22:34:46 2009 Subject: Port-forwarding with IPFW / natd Message-ID: <20091027224716.M1459@alentogroup.org> Is there any reason to prefer port-forwarding with ipfw (forward ipaddr) vs. natd (-redirect_port), if I am using both subsystems in any case? I see natd uses libalias and an ipfw divert port, so my thought is that the ipfw approach would incur less overhead. Also, the ipfw approach permits a hostname for resolving where natd requires an IP address. Thank you. From remodeler at alentogroup.org Tue Oct 27 22:46:28 2009 From: remodeler at alentogroup.org (remodeler) Date: Tue Oct 27 22:46:35 2009 Subject: Netgraph question - multiple kernels Message-ID: <20091027225454.M12540@alentogroup.org> My understanding is that I can bind multiple machines running netgraph into one large netgraph, by using something like ng_ksocket nodes bound with a tunneling device. By doing this, is the restriction of one ng_ipfw node per netgraph global to all of the machines (one, and only one, ng_ipfw node)? If the ng_ksocket nodes are connected to ng_bridges on both of the machines, will only relevant network traffic cross the link - or all network traffic? Can I configure the link between the two machines so that I can directly connect a netgraph node on one machine to a node on the other, or must they communicate by the bridge-tunnel-tunnel-bridge structure? Thank you. From stas at deglitch.com Tue Oct 27 22:48:32 2009 From: stas at deglitch.com (Stanislav Sedov) Date: Tue Oct 27 22:48:38 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: References: <4AE72910.8090708@tomjudge.com> <4AE753E4.6050205@tomjudge.com> Message-ID: <20091028024916.2507b92d.stas@deglitch.com> On Tue, 27 Oct 2009 20:30:38 -0000 "Steven Hartland" mentioned: > M610 is also broken due to unsupported bge revision :( > What bge revision do you have? I recently committed support for new bge(4) chip revisions to HEAD, can you check, please, if HEAD recognize this adapter correctly? You can boot HEAD kernel on your 7.x/8.x userland for test purposes. Thanks! -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20091027/33602c64/attachment.pgp From tom at tomjudge.com Tue Oct 27 23:01:53 2009 From: tom at tomjudge.com (Tom Judge) Date: Tue Oct 27 23:02:36 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver Message-ID: <444079893-1256682829-cardhu_decombobulator_blackberry.rim.net-789454561-@bda313.bisx.prod.on.blackberry> First sorry for the top post, the blackberry won't allow me to bottom post or I can't find the option. I will try this update when I get to the office in the morning. Hopefully it will resolve the issue. Thanks Tom ------Original Message------ From: David Christensen To: Tom Judge Cc: net@freebsd.org Cc: rwilliams@borderware.com Cc: Gideon Naim Subject: RE: bce(4) BCM5907 CTX write errors on 7.2 driver Sent: 27 Oct 2009 17:18 > Thanks for the rapid response. > > Dell have firmware 5.0.9 on their website here: http://tiny.cc/ex834 > > Will that work? Yes, that release does include a good version of BCM5709 bootcode (v5.06). I couldn't really tell until I downloaded the file and looked at the temporary files inside. Thanks for the link. Dave Sent via BlackBerry from T-Mobile From killing at multiplay.co.uk Tue Oct 27 23:02:18 2009 From: killing at multiplay.co.uk (Steven Hartland) Date: Tue Oct 27 23:02:37 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver References: <4AE72910.8090708@tomjudge.com> <4AE753E4.6050205@tomjudge.com> <20091028024916.2507b92d.stas@deglitch.com> Message-ID: Sorry I typo'ed there, should have said bce, is that still relevant?. We haven't been able to install any version yet, so can't just try a kernel, no way of getting data on to the machine without a working netcard ;-) Did this update include any updated PHY support for bce? As the the precise error indicates that as the issue, as can be seen here: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134658 If it does will this be in an ISO snapshot yet, as that's the only way of testing? Regards Steve ----- Original Message ----- From: "Stanislav Sedov" > M610 is also broken due to unsupported bge revision :( > What bge revision do you have? I recently committed support for new bge(4) chip revisions to HEAD, can you check, please, if HEAD recognize this adapter correctly? You can boot HEAD kernel on your 7.x/8.x userland for test purposes. Thanks! -- Stanislav Sedov ST4096-RIPE ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From ccowart at rescomp.berkeley.edu Tue Oct 27 23:14:35 2009 From: ccowart at rescomp.berkeley.edu (Chris Cowart) Date: Tue Oct 27 23:14:42 2009 Subject: Port-forwarding with IPFW / natd In-Reply-To: <20091027224716.M1459@alentogroup.org> References: <20091027224716.M1459@alentogroup.org> Message-ID: <20091027231434.GC11723@hal.rescomp.berkeley.edu> remodeler wrote: > Is there any reason to prefer port-forwarding with ipfw (forward ipaddr) vs. > natd (-redirect_port), if I am using both subsystems in any case? I see natd > uses libalias and an ipfw divert port, so my thought is that the ipfw approach > would incur less overhead. Also, the ipfw approach permits a hostname for > resolving where natd requires an IP address. Using natd (or ipfw nat) has the ability to manipulate the IP address and ports of a packet. The fwd capability in ipfw does not modify the layer 3 headers, but instead short-circuits the next-hop logic. Take a look at the fwd description in ipfw(8). I would recommend using the ipfw built-in nat support (search for NAT in ipfw(8)) instead of the old-style divert solution. As I understand it, divert has overhead related to copying the packets to and from userland, which is unnecessary when using the in-kernel implementation. -- Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 834 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20091027/f41f00b4/attachment.pgp From stas at deglitch.com Tue Oct 27 23:17:29 2009 From: stas at deglitch.com (Stanislav Sedov) Date: Tue Oct 27 23:17:35 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: References: <4AE72910.8090708@tomjudge.com> <4AE753E4.6050205@tomjudge.com> <20091028024916.2507b92d.stas@deglitch.com> Message-ID: <20091028031819.c965c22d.stas@deglitch.com> On Tue, 27 Oct 2009 23:02:09 -0000 "Steven Hartland" mentioned: > Sorry I typo'ed there, should have said bce, is that still relevant?. > > We haven't been able to install any version yet, so can't just > try a kernel, no way of getting data on to the machine without > a working netcard ;-) > > Did this update include any updated PHY support for bce? As the > the precise error indicates that as the issue, as can be seen here: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134658 > > If it does will this be in an ISO snapshot yet, as that's the only > way of testing? > If I understand the PR comments right, the code to support this PHY should be present in 8.0. So you can start by trying out 8.0-RC1 ISO image (or USB stick image, fwiw). -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20091027/a2833ee4/attachment.pgp From Benjamin.Close at clearchain.com Tue Oct 27 23:18:21 2009 From: Benjamin.Close at clearchain.com (Benjamin Close) Date: Tue Oct 27 23:18:28 2009 Subject: Can we turn off WPI_DEBUG In-Reply-To: <4AE77437.4090700@FreeBSD.org> References: <4AE77437.4090700@FreeBSD.org> Message-ID: <4AE77BF8.3040907@clearchain.com> On 28/10/09 08:59, Doug Barton wrote: > I cc'ed those who seem to have put the most/recent effort into > sys/dev/wpi. > > Is there any objection to turning off WPI_DEBUG by default? it creates > a lot of spam that the average user doesn't need. I use my 3945abg > every day and haven't had any problems with it for ages so I think > it's safe to say we're out of the period were debug by default is needed? > I've no objections, I was originally turned on to aid in helping user issues. Many of these seem to have now been solved. Cheers, Benjamin From killing at multiplay.co.uk Tue Oct 27 23:36:07 2009 From: killing at multiplay.co.uk (Steven Hartland) Date: Tue Oct 27 23:36:15 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver References: <4AE72910.8090708@tomjudge.com><4AE753E4.6050205@tomjudge.com><20091028024916.2507b92d.stas@deglitch.com> <20091028031819.c965c22d.stas@deglitch.com> Message-ID: <43816B76DBB041EDBFFD09C5089B7F75@multiplay.co.uk> On Tue, 27 Oct 2009 23:02:09 -0000 "Steven Hartland" mentioned: > If I understand the PR comments right, the code to support this PHY > should be present in 8.0. So you can start by trying out 8.0-RC1 > ISO image (or USB stick image, fwiw). Just tried 8.0RC2 no go, PHY still not supported :( Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From thompsa at FreeBSD.org Tue Oct 27 23:37:02 2009 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Tue Oct 27 23:37:16 2009 Subject: Can we turn off WPI_DEBUG In-Reply-To: <4AE77437.4090700@FreeBSD.org> References: <4AE77437.4090700@FreeBSD.org> Message-ID: <20091027232043.GB16914@citylink.fud.org.nz> On Tue, Oct 27, 2009 at 03:29:11PM -0700, Doug Barton wrote: > I cc'ed those who seem to have put the most/recent effort into > sys/dev/wpi. > > Is there any objection to turning off WPI_DEBUG by default? it creates > a lot of spam that the average user doesn't need. I use my 3945abg > every day and haven't had any problems with it for ages so I think > it's safe to say we're out of the period were debug by default is needed? Go for it. Andrew From julian at elischer.org Tue Oct 27 23:37:21 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Oct 27 23:37:31 2009 Subject: Port-forwarding with IPFW / natd In-Reply-To: <20091027224716.M1459@alentogroup.org> References: <20091027224716.M1459@alentogroup.org> Message-ID: <4AE78430.5070305@elischer.org> remodeler wrote: > Is there any reason to prefer port-forwarding with ipfw (forward ipaddr) vs. > natd (-redirect_port), if I am using both subsystems in any case? I see natd > uses libalias and an ipfw divert port, so my thought is that the ipfw approach > would incur less overhead. Also, the ipfw approach permits a hostname for > resolving where natd requires an IP address. they do different things NAT changes the packets while fwd leaves them alone but just changes where they are delivered. which you use depends on what you are trying to do. > > Thank you. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From julian at elischer.org Tue Oct 27 23:41:55 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Oct 27 23:42:01 2009 Subject: Netgraph question - multiple kernels In-Reply-To: <20091027225454.M12540@alentogroup.org> References: <20091027225454.M12540@alentogroup.org> Message-ID: <4AE78541.50700@elischer.org> remodeler wrote: > My understanding is that I can bind multiple machines running netgraph into > one large netgraph, by using something like ng_ksocket nodes bound with a > tunneling device. you COULD do that, yes, but the two netgraphs are unaware of each other. > > By doing this, is the restriction of one ng_ipfw node per netgraph global to > all of the machines (one, and only one, ng_ipfw node)? no it's one per machine > If the ng_ksocket nodes > are connected to ng_bridges on both of the machines, will only relevant > network traffic cross the link - or all network traffic? ng_bridge does MAC address filtering. it only sends no broadcast packets to teh link where it has seen packets coming from that mac address. > Can I configure the > link between the two machines so that I can directly connect a netgraph node > on one machine to a node on the other, or must they communicate by the > bridge-tunnel-tunnel-bridge structure? You are sending the packet out of one netgraph and into another. how you get the packet there is your business.. you could use two ng_ether nodes and use a dedicated ethernet as a low latency tunnel. > > Thank you. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From kris at FreeBSD.org Wed Oct 28 01:15:22 2009 From: kris at FreeBSD.org (Kris Kennaway) Date: Wed Oct 28 01:15:28 2009 Subject: ZFS and 'traditional' nfs-export In-Reply-To: References: <00b301ca5739$8e9b3850$abd1a8f0$@org> Message-ID: <4AE79B37.5010203@FreeBSD.org> Arno J. Klaassen wrote: > hello, > > "Larry Rosenman" writes: > >> ZFS makes its own version of the exports file. >> >> Just do it that way, and be safe. >> >> You can pass the full set of NFS options in the sharenfs parameter.... > > ah ok, I see. Thanks for answering. > > I got fooled by the man zfs(1M) example : > > zfs set sharenfs='rw=@123.123.0.0/16,root=neo' tank/home > > This syntax does not seem to work for me (8.0RC2). > Maybe an extra line could be added that one can just set > the sharenfs property to exactly the same character string > as in /etc/exports. Yeah that is the solaris notation -- various things in the manpages have not yet been customized for FreeBSD, which can be a bit confusing. The only limitation I've found in using sharenfs is that you can't specify multiple exports for the same filesystem, e.g. exporting to different hosts/networks with different options. The solaris notation above allows you to express this. Kris From randy at psg.com Wed Oct 28 03:20:47 2009 From: randy at psg.com (Randy Bush) Date: Wed Oct 28 03:20:54 2009 Subject: Port-forwarding with IPFW / natd In-Reply-To: <20091027231434.GC11723@hal.rescomp.berkeley.edu> References: <20091027224716.M1459@alentogroup.org> <20091027231434.GC11723@hal.rescomp.berkeley.edu> Message-ID: > Using natd (or ipfw nat) has the ability to manipulate the IP address > and ports of a packet. The fwd capability in ipfw does not modify the > layer 3 headers, but instead short-circuits the next-hop logic. Take a > look at the fwd description in ipfw(8). > > I would recommend using the ipfw built-in nat support (search for NAT in > ipfw(8)) instead of the old-style divert solution. As I understand it, > divert has overhead related to copying the packets to and from userland, > which is unnecessary when using the in-kernel implementation. i keep circling this area too. my problem is that i use the nat of ppp for the external pppoe. but i want to redirect inbound ssh to a particular server. randy From tom at tomjudge.com Wed Oct 28 03:34:13 2009 From: tom at tomjudge.com (Tom Judge) Date: Wed Oct 28 03:34:20 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: <43816B76DBB041EDBFFD09C5089B7F75@multiplay.co.uk> References: <4AE72910.8090708@tomjudge.com><4AE753E4.6050205@tomjudge.com><20091028024916.2507b92d.stas@deglitch.com> <20091028031819.c965c22d.stas@deglitch.com> <43816B76DBB041EDBFFD09C5089B7F75@multiplay.co.uk> Message-ID: <4AE7BB7B.5060503@tomjudge.com> Steven Hartland wrote: > > On Tue, 27 Oct 2009 23:02:09 -0000 > "Steven Hartland" mentioned: > >> If I understand the PR comments right, the code to support this PHY >> should be present in 8.0. So you can start by trying out 8.0-RC1 >> ISO image (or USB stick image, fwiw). > > Just tried 8.0RC2 no go, PHY still not supported :( > Looking though the mii code it seems the SerDes PHY support was moved into the brgphy code in 2007. This driver however only seems to support the 5708S PHY and not the 5709. Maybe David can shed some light on the support for this. Tom From linimon at FreeBSD.org Wed Oct 28 08:21:24 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Oct 28 08:21:31 2009 Subject: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock Message-ID: <200910280821.n9S8LNY8073427@freefall.freebsd.org> Old Synopsis: lock order reversal with iwn0_com_lock and iwn0 softc lock New Synopsis: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Oct 28 08:20:57 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=140036 From Ivor.Prebeg at fer.hr Wed Oct 28 09:31:50 2009 From: Ivor.Prebeg at fer.hr (Ivor Prebeg) Date: Wed Oct 28 11:26:12 2009 Subject: LINKSYS WUSB600N, 802.11a/b/g Message-ID: Does anyone know if this usb wifi adapter [LINKSYS WUSB600N, 802.11a/b/g] works with -CURRENT or 8.0-RC? Thanks Ivor From brueffer at FreeBSD.org Wed Oct 28 12:11:18 2009 From: brueffer at FreeBSD.org (brueffer@FreeBSD.org) Date: Wed Oct 28 12:11:24 2009 Subject: kern/138130: [netinet] [patch] Resource leak in LibAliasRefreshModules() in file sys/netinet/libalias/alias.c Message-ID: <200910281211.n9SCBI9L074490@freefall.freebsd.org> Synopsis: [netinet] [patch] Resource leak in LibAliasRefreshModules() in file sys/netinet/libalias/alias.c State-Changed-From-To: open->patched State-Changed-By: brueffer State-Changed-When: Wed Oct 28 13:10:37 CET 2009 State-Changed-Why: Committed, thanks! Responsible-Changed-From-To: freebsd-net->brueffer Responsible-Changed-By: brueffer Responsible-Changed-When: Wed Oct 28 13:10:37 CET 2009 Responsible-Changed-Why: MFC reminder. http://www.freebsd.org/cgi/query-pr.cgi?pr=138130 From ml at netfence.it Wed Oct 28 14:35:11 2009 From: ml at netfence.it (Andrea Venturoli) Date: Wed Oct 28 14:35:17 2009 Subject: snort on multiple interfaces Message-ID: <4AE8569C.1040209@netfence.it> Some years ago, I checked to see whether I would be able to let a single snort process listen on more than one NIC. At the time it was only possible in Linux. Now, I searched a bit, but nothing new came up. Did anything improve since then? Do we still need multiple snort processes to listen on more than one interface? Can some netgraph node help with this? bye & Thanks av. From sh at keff.org Wed Oct 28 14:43:02 2009 From: sh at keff.org (Sebastian Hyrwall) Date: Wed Oct 28 14:43:08 2009 Subject: Hi. Regarding "automatic vlan creation" Message-ID: <4AE852C1.8090103@keff.org> Hi Now that FreeBSD has support for writing , cloned_interfaces="em0.100" instead of having to create for example a vlan0 and then specify vlandev etc in ifconfig. What is the correct ifconfig-line in rc.conf for this? ifconfig_em0.100="" or ifconfig_em0_100="" does not work. Sincerely, Sebastian H From dudu at dudu.ro Wed Oct 28 14:43:29 2009 From: dudu at dudu.ro (Vlad Galu) Date: Wed Oct 28 14:43:35 2009 Subject: snort on multiple interfaces In-Reply-To: <4AE8569C.1040209@netfence.it> References: <4AE8569C.1040209@netfence.it> Message-ID: On Wed, Oct 28, 2009 at 4:35 PM, Andrea Venturoli wrote: > Some years ago, I checked to see whether I would be able to let a single > snort process listen on more than one NIC. > At the time it was only possible in Linux. > In Linux the packet capture facility is implemented in a different (and very inefficient manner), via raw sockets (which means that, in order to reach userspace, a packet has to travel the whole IP stack - including firewall - until delivery to the user process). BSD has BPF, which basically delivers a copy of the packet to the userspace right before it enters the IP stack for kernel processing. Each network driver does this through the BPF_TAP() macro. > Now, I searched a bit, but nothing new came up. > > Did anything improve since then? Do we still need multiple snort processes > to listen on more than one interface? > Can some netgraph node help with this? You can try lagg(4) with the "loadbalance" option, ng_one2many(4), or ng_fec(4). > > ?bye & Thanks > ? ? ? ?av. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From tom at tomjudge.com Wed Oct 28 14:48:28 2009 From: tom at tomjudge.com (Tom Judge) Date: Wed Oct 28 14:48:33 2009 Subject: snort on multiple interfaces In-Reply-To: <4AE8569C.1040209@netfence.it> References: <4AE8569C.1040209@netfence.it> Message-ID: <4AE85985.5080206@tomjudge.com> Andrea Venturoli wrote: > Some years ago, I checked to see whether I would be able to let a > single snort process listen on more than one NIC. > At the time it was only possible in Linux. > > Now, I searched a bit, but nothing new came up. > > Did anything improve since then? Do we still need multiple snort > processes to listen on more than one interface? > Can some netgraph node help with this? > You can do this using if_bridge in monitor mode like so: {/etc/rc.conf} ## DMZ Span Port cloned_interfaces="bridge0" ifconfig_fxp0="up promisc" ifconfig_fxp1="up promisc" ifconfig_bridge0="addm fxp0 addm fxp1 monitor up" And then have you snort process run on bridge0. Tom From artis.caune at gmail.com Wed Oct 28 15:00:51 2009 From: artis.caune at gmail.com (Artis Caune) Date: Wed Oct 28 15:00:57 2009 Subject: Hi. Regarding "automatic vlan creation" In-Reply-To: <4AE852C1.8090103@keff.org> References: <4AE852C1.8090103@keff.org> Message-ID: <9e20d71e0910280800q212d0235p8d7c7c4e07a8c9b6@mail.gmail.com> 2009/10/28 Sebastian Hyrwall : > Hi > > Now that FreeBSD has support for writing ?, cloned_interfaces="em0.100" > instead of having to create for example a vlan0 and then specify vlandev etc > in ifconfig. What is the correct ifconfig-line in rc.conf for this? > > ifconfig_em0.100="" or ifconfig_em0_100="" does not work. You probably forgot to put if_vlan_load="YES" in /boot/loader.conf ifconfig_em0_100="..." should work. -- Artis Caune Everything should be made as simple as possible, but not simpler. From sh at keff.org Wed Oct 28 15:25:40 2009 From: sh at keff.org (Sebastian Hyrwall) Date: Wed Oct 28 15:25:47 2009 Subject: Hi. Regarding "automatic vlan creation" In-Reply-To: <9e20d71e0910280800q212d0235p8d7c7c4e07a8c9b6@mail.gmail.com> References: <4AE852C1.8090103@keff.org> <9e20d71e0910280800q212d0235p8d7c7c4e07a8c9b6@mail.gmail.com> Message-ID: <4AE8626E.8080505@keff.org> Hi. Ah ok. Well I did add that but maybe there was a typo somewhere else. Unfortuently I can't reach the server anymore (i wonder why heh ;) so I gave this email a try before going to the datacenter to fix it. Thanks for the input. Artis Caune skrev: > 2009/10/28 Sebastian Hyrwall : > >> Hi >> >> Now that FreeBSD has support for writing , cloned_interfaces="em0.100" >> instead of having to create for example a vlan0 and then specify vlandev etc >> in ifconfig. What is the correct ifconfig-line in rc.conf for this? >> >> ifconfig_em0.100="" or ifconfig_em0_100="" does not work. >> > > You probably forgot to put if_vlan_load="YES" in /boot/loader.conf > ifconfig_em0_100="..." should work. > > > > > From glenbarner at australia.edu Wed Oct 28 14:46:12 2009 From: glenbarner at australia.edu (glenn Barber) Date: Wed Oct 28 15:44:49 2009 Subject: 82575 NIC can't work with LAGG Message-ID: <5794edfe0910280713i68dbe43cxc40ced80bd0bf372@mail.gmail.com> In FreeBSD 8.0-RC1, igb can't work with lagg, however, em(82571) works. Is there something weird with igb driver? From jon at witchspace.com Wed Oct 28 16:27:38 2009 From: jon at witchspace.com (Jonathan Belson) Date: Wed Oct 28 16:27:45 2009 Subject: PF and DHCP Message-ID: <75F8B8C2-2BFE-434A-9E16-C34CAAF6C6E9@witchspace.com> Hiya I have a server which acts as a gateway between the internet and my internal network. The external interface receives its IP address via DHCP. I set up pf.conf to allow DHCP packets via ports 67/68, but I notice that when the server boots, the DHCP exchange happens /before/ PF gets started. Does this mean that adding rules for DHCP isn't necessary (my firewall rules are block in/pass out, with a bit of NAT thrown in)? Does this mean that when my machine boots, there's a window between the interfaces coming up and the firewall being enabled? Thanks, --Jon From spawk at acm.poly.edu Wed Oct 28 16:33:33 2009 From: spawk at acm.poly.edu (Boris Kochergin) Date: Wed Oct 28 16:33:39 2009 Subject: PF and DHCP In-Reply-To: <75F8B8C2-2BFE-434A-9E16-C34CAAF6C6E9@witchspace.com> References: <75F8B8C2-2BFE-434A-9E16-C34CAAF6C6E9@witchspace.com> Message-ID: <4AE8724F.50702@acm.poly.edu> Jonathan Belson wrote: > Hiya > > I have a server which acts as a gateway between the internet and my > internal network. The external interface receives its IP address via > DHCP. I set up pf.conf to allow DHCP packets via ports 67/68, but I > notice that when the server boots, the DHCP exchange happens /before/ > PF gets started. > > Does this mean that adding rules for DHCP isn't necessary (my firewall > rules are block in/pass out, with a bit of NAT thrown in)? To address just this question, it is a good idea to leave the rules that allow DHCP in there, as the DHCP client will need to renew its lease later, while the firewall is running. -Boris > Does this mean that when my machine boots, there's a window between > the interfaces coming up and the firewall being enabled? > > Thanks, > > --Jon > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From brooks at freebsd.org Wed Oct 28 16:44:48 2009 From: brooks at freebsd.org (Brooks Davis) Date: Wed Oct 28 16:44:54 2009 Subject: Hi. Regarding "automatic vlan creation" In-Reply-To: <4AE852C1.8090103@keff.org> References: <4AE852C1.8090103@keff.org> Message-ID: <20091028164330.GA71430@lor.one-eyed-alien.net> On Wed, Oct 28, 2009 at 03:18:41PM +0100, Sebastian Hyrwall wrote: > Hi > > Now that FreeBSD has support for writing , cloned_interfaces="em0.100" > instead of having to create for example a vlan0 and then specify vlandev > etc in ifconfig. What is the correct ifconfig-line in rc.conf for this? > > ifconfig_em0.100="" or ifconfig_em0_100="" does not work. It should be ifconfig_em0_100. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20091028/e4ba5f6a/attachment.pgp From pjd at FreeBSD.org Wed Oct 28 18:23:29 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Wed Oct 28 18:23:36 2009 Subject: ZFS and 'traditional' nfs-export In-Reply-To: References: Message-ID: <20091028175433.GA1671@garage.freebsd.pl> On Tue, Oct 27, 2009 at 12:46:00AM +0100, Arno J. Klaassen wrote: > > Hello, > > I googled a bit on this question but could not find > a clear answer : > > is there any risk/inconvenience/advantage in exporting > a ZFS-fs by just putting it in /etc/exports the old > way and leaving the 'sharenfs' option on the filesystem off? > > I'd like to replace a UFS-based server serving mostly > linux-clients which work well now with a ZFS-fs, and somehow > am a bit waterfearing changing the nfs?options which worked > great till now. You can safely use /etc/exports without touching sharenfs property. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20091028/091db385/attachment.pgp From linimon at FreeBSD.org Wed Oct 28 18:37:52 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Oct 28 18:38:03 2009 Subject: kern/140051: [bce] [arp] ARP not sent through Bridge Firewall with BCE network dirver Message-ID: <200910281837.n9SIbpaI001975@freefall.freebsd.org> Old Synopsis: ARP not sent through Bridge Firewall with BCE network dirver New Synopsis: [bce] [arp] ARP not sent through Bridge Firewall with BCE network dirver Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Oct 28 18:37:36 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=140051 From artis.caune at gmail.com Wed Oct 28 22:31:55 2009 From: artis.caune at gmail.com (Artis Caune) Date: Wed Oct 28 22:32:02 2009 Subject: Hi. Regarding "automatic vlan creation" In-Reply-To: <20091028164330.GA71430@lor.one-eyed-alien.net> References: <4AE852C1.8090103@keff.org> <20091028164330.GA71430@lor.one-eyed-alien.net> Message-ID: <9e20d71e0910281531o56d82709ife0b76a59bff5f23@mail.gmail.com> 2009/10/28 Brooks Davis : > On Wed, Oct 28, 2009 at 03:18:41PM +0100, Sebastian Hyrwall wrote: >> Hi >> >> Now that FreeBSD has support for writing ?, cloned_interfaces="em0.100" >> instead of having to create for example a vlan0 and then specify vlandev >> etc in ifconfig. What is the correct ifconfig-line in rc.conf for this? >> >> ifconfig_em0.100="" or ifconfig_em0_100="" does not work. > > It should be ifconfig_em0_100. btw, wouldn't it be nice not to bother with loader.conf when using . syntax? This patch will load if_vlan automatically in this case: --- sbin/ifconfig/ifconfig.c 2009-10-26 14:11:16 +0000 +++ sbin/ifconfig/ifconfig.c 2009-10-28 21:43:07 +0000 @@ -998,6 +998,10 @@ break; } + /* try to load vlan module if interface name is device.vlan_id */ + if (index(name, '.') != NULL) + strlcpy(ifname, "vlan", sizeof(ifname)); + /* turn interface and unit into module name */ strcpy(ifkind, "if_"); strlcpy(ifkind + MOD_PREFIX_LEN, ifname, -- Artis Caune Everything should be made as simple as possible, but not simpler. From tom at tomjudge.com Wed Oct 28 22:58:25 2009 From: tom at tomjudge.com (Tom Judge) Date: Wed Oct 28 22:58:32 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: <5D267A3F22FD854F8F48B3D2B52381933A04B491AE@IRVEXCHCCR01.corp.ad.broadcom.com> References: <4AE72910.8090708@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B49180@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE76FF1.9010401@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B491AE@IRVEXCHCCR01.corp.ad.broadcom.com> Message-ID: <4AE8CC59.7020004@tomjudge.com> David Christensen wrote: >> Thanks for the rapid response. >> >> Dell have firmware 5.0.9 on their website here: http://tiny.cc/ex834 >> >> Will that work? > > Yes, that release does include a good version of BCM5709 bootcode (v5.06). > I couldn't really tell until I downloaded the file and looked at the > temporary files inside. Thanks for the link. > > After fighting with the update process for a bit and then learning about the live cycle manager I have managed to test the R610 with the 5.0.9 firmware. On the face of it, it seems that this resolves the issue. Tom From sten at blinkenlights.nl Wed Oct 28 23:10:05 2009 From: sten at blinkenlights.nl (Sten Spans) Date: Wed Oct 28 23:10:15 2009 Subject: kern/139145: IPv6 blackhole / reject routes broken Message-ID: <200910282310.n9SNA5Bu032339@freefall.freebsd.org> The following reply was made to PR kern/139145; it has been noted by GNATS. From: Sten Spans To: FreeBSD-gnats-submit@FreeBSD.org Cc: Subject: Re: kern/139145: IPv6 blackhole / reject routes broken Date: Thu, 29 Oct 2009 00:05:45 +0100 (CET) On Fri, 25 Sep 2009, FreeBSD-gnats-submit@FreeBSD.org wrote: >> Category: kern >> Responsible: freebsd-bugs >> Synopsis: IPv6 blackhole / reject routes broken >> Arrival-Date: Fri Sep 25 22:50:01 UTC 2009 Not sure which commit fixed it but this issue seems to be fixed in 8.0-RC2: traceroute to 2a02:898:17:1234:: (2a02:898:17:1234::) from 2001:7b8:666:ffff:0:42ff:fe00:4, 30 hops max, 24 byte packets 1 gw.deepthought.blinkenlights.nl (2001:7b8:666:ffff::1) 0.292 ms 0.227 ms 0.193 ms 2 hobby-gw.jun1.galilei.network.bit.nl (2001:7b8:3:47::2) 0.357 ms 0.402 ms 0.461 ms 3 nikhef.ams-ix.ipv6.intouch.net (2001:7f8:1::a500:8954:1) 2.603 ms 2.494 ms 2.234 ms 4 2001:6e0:8954:205b:1::2 (2001:6e0:8954:205b:1::2) 5.103 ms 5.144 ms 5.829 ms 5 ge-0-0-1-0.dcg-1.ipv6.coloclue.net (2a02:898:0:301::a) 5.238 ms 6.026 ms 6.345 ms 6 eddie.blinkenlights.nl (2a02:898::74:2) 3.18 ms 3.158 ms 4.044 ms 7 * * * -- Sten Spans "There is a crack in everything, that's how the light gets in." Leonard Cohen - Anthem From brooks at freebsd.org Thu Oct 29 00:09:40 2009 From: brooks at freebsd.org (Brooks Davis) Date: Thu Oct 29 00:09:47 2009 Subject: Hi. Regarding "automatic vlan creation" In-Reply-To: <9e20d71e0910281531o56d82709ife0b76a59bff5f23@mail.gmail.com> References: <4AE852C1.8090103@keff.org> <20091028164330.GA71430@lor.one-eyed-alien.net> <9e20d71e0910281531o56d82709ife0b76a59bff5f23@mail.gmail.com> Message-ID: <20091029000822.GA74744@lor.one-eyed-alien.net> On Thu, Oct 29, 2009 at 12:31:49AM +0200, Artis Caune wrote: > 2009/10/28 Brooks Davis : > > On Wed, Oct 28, 2009 at 03:18:41PM +0100, Sebastian Hyrwall wrote: > >> Hi > >> > >> Now that FreeBSD has support for writing ??, cloned_interfaces="em0.100" > >> instead of having to create for example a vlan0 and then specify vlandev > >> etc in ifconfig. What is the correct ifconfig-line in rc.conf for this? > >> > >> ifconfig_em0.100="" or ifconfig_em0_100="" does not work. > > > > It should be ifconfig_em0_100. > > btw, wouldn't it be nice not to bother with loader.conf when using > . syntax? > This patch will load if_vlan automatically in this case: Sorry but my reation is: eww. There's no way I'd commit that. You'd be randomly loading the vlan code for any interface that had a dot in it. The real change we should make it to add device vlan to GENERIC. It's long past time for it to be in by default. -- Brooks > --- sbin/ifconfig/ifconfig.c 2009-10-26 14:11:16 +0000 > +++ sbin/ifconfig/ifconfig.c 2009-10-28 21:43:07 +0000 > @@ -998,6 +998,10 @@ > break; > } > > + /* try to load vlan module if interface name is device.vlan_id */ > + if (index(name, '.') != NULL) > + strlcpy(ifname, "vlan", sizeof(ifname)); > + > /* turn interface and unit into module name */ > strcpy(ifkind, "if_"); > strlcpy(ifkind + MOD_PREFIX_LEN, ifname, > > > > > > -- > Artis Caune > > Everything should be made as simple as possible, but not simpler. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20091029/4c3a591a/attachment.pgp From atkin901 at yahoo.com Thu Oct 29 00:10:04 2009 From: atkin901 at yahoo.com (Mark Atkinson) Date: Thu Oct 29 00:10:10 2009 Subject: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Message-ID: <200910290010.n9T0A3cV083541@freefall.freebsd.org> The following reply was made to PR kern/124127; it has been noted by GNATS. From: Mark Atkinson To: freebsd prs Cc: Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Date: Wed, 28 Oct 2009 17:03:52 -0700 (PDT) =0A=0AOn the unpatched -current kernel, built=0A=0AFreeBSD hellfire.filamen= t.org 9.0-CURRENT FreeBSD 9.0-CURRENT #14: Mon Oct 19 09:12:03 PDT 2009 =0A= =0AI recieved the following panic today related to this:=0A=0AFatal trap 12= : page fault while in kernel mode=0Acpuid =3D 0; apic id =3D 00=0Afault vir= tual address =3D 0xdeadc10a=0Afault code =3D supervisor read= , page not present=0Ainstruction pointer =3D 0x20:0xc0987410=0Astack po= inter =3D 0x28:0xd533dac0=0Aframe pointer =3D 0x28:0xd5= 33dae8=0Acode segment =3D base 0x0, limit 0xfffff, type 0x1b=0A = =3D DPL 0, pres 1, def32 1, gran 1=0Aprocessor eflag= s =3D interrupt enabled, resume, IOPL =3D 0=0Acurrent process = =3D 0 (mskc0 taskq)=0APhysical memory: 495 MB=0ADumping 132 MB: 117 101 8= 5 69 53 37 21 5=0A=0AReading symbols from /boot/kernel/linux.ko...Reading s= ymbols from /boot/kernel/linux.ko.symbols...done.=0Adone.=0ALoaded symbols = for /boot/kernel/linux.ko=0A#0 0xc08907a9 in doadump () at /usr/src/sys/ke= rn/kern_shutdown.c:254=0A254 }=0A(kgdb) bt=0A#0 0xc08907a9 in doadump = () at /usr/src/sys/kern/kern_shutdown.c:254=0A#1 0xc04f7e37 in db_fncall (= dummy1=3D-1067299898, dummy2=3D0, dummy3=3D-718022488,=0A dummy4=3D0xd53= 3d898 "\200%t=C3") at /usr/src/sys/ddb/db_command.c:548=0A#2 0xc04f8214 in= db_command (last_cmdp=3D0xc0da059c, cmd_table=3D0x0, dopager=3D1)=0A at= /usr/src/sys/ddb/db_command.c:445=0A#3 0xc04f8352 in db_command_loop () a= t /usr/src/sys/ddb/db_command.c:498=0A#4 0xc04fa05e in db_trap (type=3D12,= code=3D0) at /usr/src/sys/ddb/db_main.c:229=0A#5 0xc08bf2d2 in kdb_reente= r () at /usr/src/sys/kern/subr_kdb.c:398=0A#6 0xc0ba9b62 in trap_fatal (fr= ame=3D0x1, eva=3D3735929098)=0A at /usr/src/sys/i386/i386/trap.c:938=0A#= 7 0xc0baa483 in trap (frame=3D0xd533da80) at /usr/src/sys/i386/i386/trap.c= :339=0A#8 0xc0b8e4ab in Xlcall_syscall () at /usr/src/sys/i386/i386/except= ion.s:241=0A#9 0xc0987410 in in_lltable_lookup (llt=3D0xc39e1000, flags=3D= Variable "flags" is not available.=0A)=0A at /usr/src/sys/netinet/in.c:1= 380=0A#10 0xc0982470 in arpintr (m=3D0xc3baeb00) at /usr/src/sys/netinet/if= _ether.c:642=0A#11 0xc094227a in netisr_dispatch_src (proto=3D7, source=3D0= , m=3D0xc0de)=0A at /usr/src/sys/net/netisr.c:932=0A#12 0xc09424dd in ne= tisr_unregister (nhp=3D0xc0de)=0A at /usr/src/sys/net/netisr.c:583=0A#13= 0xc093ac69 in ether_demux (ifp=3D0x0, m=3D0xc3baeb00)=0A at /usr/src/sy= s/net/if_ethersubr.c:911=0A#14 0xc093b1ce in ether_output (ifp=3D0xc36ad400= , m=3D0xc3baeb00, dst=3D0xc0c55c27,=0A ro=3D0x301010a) at /usr/src/sys/n= et/if_ethersubr.c:181=0A---Type to continue, or q to quit= ---=0A#15 0xc070b032 in msk_handle_events (sc=3D0xc3686c00)=0A at /usr/s= rc/sys/dev/msk/if_msk.c:3048=0A#16 0xc070b828 in msk_int_task (arg=3D0xc368= 6c00, pending=3D1)=0A at /usr/src/sys/dev/msk/if_msk.c:3625=0A#17 0xc08c= ac8c in taskqueue_run (queue=3D0xc36bf380)=0A at /usr/src/sys/kern/subr_= taskqueue.c:72=0A#18 0xc08cadcc in taskqueue_thread_loop (arg=3D0xc3686c8c)= =0A at /usr/src/sys/kern/subr_taskqueue.c:90=0A#19 0xc0869271 in fork_ex= it (callout=3D0xc08cad67 ,=0A arg=3D0xc3686c8c= , frame=3D0xd533dd38) at /usr/src/sys/kern/kern_fork.c:854=0A#20 0xc0b8e520= in Xatpic_intr0 () at atpic_vector.s:62=0A#21 0x00000000 in ?? ()=0A=0A=0A= From qing.li at bluecoat.com Thu Oct 29 01:44:36 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Thu Oct 29 01:44:43 2009 Subject: kern/139145: IPv6 blackhole / reject routes broken In-Reply-To: <200910282310.n9SNA5Bu032339@freefall.freebsd.org> References: <200910282310.n9SNA5Bu032339@freefall.freebsd.org> Message-ID: I remember looking at this bug and tried to reproduce it ... If my memory serves me right, I believe this bug was fixed by svn r197364, committed on 9/20. RC1 was built on 9/17. Another symptom of this bug is the "route get" command issued on any lo0 addresses returns "destination: default" instead of "destination: lo0". -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Sten Spans > Sent: Wednesday, October 28, 2009 4:10 PM > To: freebsd-net@freebsd.org > Subject: Re: kern/139145: IPv6 blackhole / reject routes broken > > The following reply was made to PR kern/139145; it has been noted by > GNATS. > > From: Sten Spans > To: FreeBSD-gnats-submit@FreeBSD.org > Cc: > Subject: Re: kern/139145: IPv6 blackhole / reject routes broken > Date: Thu, 29 Oct 2009 00:05:45 +0100 (CET) > > On Fri, 25 Sep 2009, FreeBSD-gnats-submit@FreeBSD.org wrote: > > >> Category: kern > >> Responsible: freebsd-bugs > >> Synopsis: IPv6 blackhole / reject routes broken > >> Arrival-Date: Fri Sep 25 22:50:01 UTC 2009 > > Not sure which commit fixed it but this issue seems to > be fixed in 8.0-RC2: > > traceroute to 2a02:898:17:1234:: (2a02:898:17:1234::) from > 2001:7b8:666:ffff:0:42ff:fe00:4, 30 hops max, 24 byte packets > 1 gw.deepthought.blinkenlights.nl (2001:7b8:666:ffff::1) 0.292 ms > 0.227 ms 0.193 ms > 2 hobby-gw.jun1.galilei.network.bit.nl (2001:7b8:3:47::2) 0.357 ms > 0.402 ms 0.461 ms > 3 nikhef.ams-ix.ipv6.intouch.net (2001:7f8:1::a500:8954:1) 2.603 > ms 2.494 ms 2.234 ms > 4 2001:6e0:8954:205b:1::2 (2001:6e0:8954:205b:1::2) 5.103 ms > 5.144 ms 5.829 ms > 5 ge-0-0-1-0.dcg-1.ipv6.coloclue.net (2a02:898:0:301::a) 5.238 ms > 6.026 ms 6.345 ms > 6 eddie.blinkenlights.nl (2a02:898::74:2) 3.18 ms 3.158 ms 4.044 > ms > 7 * * * > > -- > Sten Spans > > "There is a crack in everything, that's how the light gets in." > Leonard Cohen - Anthem > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From sten at blinkenlights.nl Thu Oct 29 07:33:05 2009 From: sten at blinkenlights.nl (Sten Spans) Date: Thu Oct 29 07:34:32 2009 Subject: kern/139145: IPv6 blackhole / reject routes broken In-Reply-To: References: <200910282310.n9SNA5Bu032339@freefall.freebsd.org> Message-ID: On Wed, 28 Oct 2009, Li, Qing wrote: > I remember looking at this bug and tried to reproduce it ... > > If my memory serves me right, I believe this bug was fixed by > svn r197364, committed on 9/20. RC1 was built on 9/17. > > Another symptom of this bug is the "route get" command issued > on any lo0 addresses returns "destination: default" instead > of "destination: lo0". That indeed looks like the culprit, thanks for fixing it. -- Sten Spans "There is a crack in everything, that's how the light gets in." Leonard Cohen - Anthem From sten at blinkenlights.nl Thu Oct 29 07:40:03 2009 From: sten at blinkenlights.nl (Sten Spans) Date: Thu Oct 29 07:40:17 2009 Subject: kern/139145: IPv6 blackhole / reject routes broken Message-ID: <200910290740.n9T7e2Au003929@freefall.freebsd.org> The following reply was made to PR kern/139145; it has been noted by GNATS. From: Sten Spans To: "Li, Qing" Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-net@freebsd.org Subject: RE: kern/139145: IPv6 blackhole / reject routes broken Date: Thu, 29 Oct 2009 08:33:03 +0100 (CET) On Wed, 28 Oct 2009, Li, Qing wrote: > I remember looking at this bug and tried to reproduce it ... > > If my memory serves me right, I believe this bug was fixed by > svn r197364, committed on 9/20. RC1 was built on 9/17. > > Another symptom of this bug is the "route get" command issued > on any lo0 addresses returns "destination: default" instead > of "destination: lo0". That indeed looks like the culprit, thanks for fixing it. -- Sten Spans "There is a crack in everything, that's how the light gets in." Leonard Cohen - Anthem From bschmidt at techwires.net Thu Oct 29 07:40:04 2009 From: bschmidt at techwires.net (Bernhard Schmidt) Date: Thu Oct 29 07:40:18 2009 Subject: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock Message-ID: <200910290740.n9T7e3nj003955@freefall.freebsd.org> The following reply was made to PR kern/140036; it has been noted by GNATS. From: Bernhard Schmidt To: bug-followup@freebsd.org, kaduk@mit.edu Cc: Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock Date: Thu, 29 Oct 2009 08:19:44 +0100 Hi, Removing the IWN_LOCK(sc) leads to races when calling iwn_cmd(). It's better to drop the IEEE80211_LOCK(ic). I do have a patch in test which hopefully will hit the tree soon. -- Bernhard From artis.caune at gmail.com Thu Oct 29 09:17:29 2009 From: artis.caune at gmail.com (Artis Caune) Date: Thu Oct 29 09:17:35 2009 Subject: Hi. Regarding "automatic vlan creation" In-Reply-To: <20091029000822.GA74744@lor.one-eyed-alien.net> References: <4AE852C1.8090103@keff.org> <20091028164330.GA71430@lor.one-eyed-alien.net> <9e20d71e0910281531o56d82709ife0b76a59bff5f23@mail.gmail.com> <20091029000822.GA74744@lor.one-eyed-alien.net> Message-ID: <9e20d71e0910290217k58493c3enb7dc303f50385533@mail.gmail.com> 2009/10/29 Brooks Davis : >> btw, wouldn't it be nice not to bother with loader.conf when using >> . syntax? >> This patch will load if_vlan automatically in this case: > > Sorry but my reation is: eww. ?There's no way I'd commit that. ?You'd be > randomly loading the vlan code for any interface that had a dot in it. You are right, forgot about 'ifconfig rename'. > The real change we should make it to add device vlan to GENERIC. ?It's > long past time for it to be in by default. It's even better, what's need to be done to move it to GENERIC? -- Artis Caune Everything should be made as simple as possible, but not simpler. From atkin901 at yahoo.com Thu Oct 29 13:53:02 2009 From: atkin901 at yahoo.com (Mark Atkinson) Date: Thu Oct 29 13:53:09 2009 Subject: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering In-Reply-To: <200910290010.n9T0A3cV083541@freefall.freebsd.org> References: <200910290010.n9T0A3cV083541@freefall.freebsd.org> Message-ID: Wow, not sure what to blame for that charset nightmare. Apologies. Here's the original message: On the unpatched -current kernel, built FreeBSD hellfire.filament.org 9.0-CURRENT FreeBSD 9.0-CURRENT #14: Mon Oct 19 09:12:03 PDT 2009 I recieved the following panic today related to this: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xdeadc10a fault code = supervisor read, page not present instruction pointer = 0x20:0xc0987410 stack pointer = 0x28:0xd533dac0 frame pointer = 0x28:0xd533dae8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (mskc0 taskq) Physical memory: 495 MB Dumping 132 MB: 117 101 85 69 53 37 21 5 Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko #0 0xc08907a9 in doadump () at /usr/src/sys/kern/kern_shutdown.c:254 254 } (kgdb) bt #0 0xc08907a9 in doadump () at /usr/src/sys/kern/kern_shutdown.c:254 #1 0xc04f7e37 in db_fncall (dummy1=-1067299898, dummy2=0, dummy3=-718022488, dummy4=0xd533d898 "\200%t?") at /usr/src/sys/ddb/db_command.c:548 #2 0xc04f8214 in db_command (last_cmdp=0xc0da059c, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc04f8352 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xc04fa05e in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 #5 0xc08bf2d2 in kdb_reenter () at /usr/src/sys/kern/subr_kdb.c:398 #6 0xc0ba9b62 in trap_fatal (frame=0x1, eva=3735929098) at /usr/src/sys/i386/i386/trap.c:938 #7 0xc0baa483 in trap (frame=0xd533da80) at /usr/src/sys/i386/i386/trap.c:339 #8 0xc0b8e4ab in Xlcall_syscall () at /usr/src/sys/i386/i386/exception.s:241 #9 0xc0987410 in in_lltable_lookup (llt=0xc39e1000, flags=Variable "flags" is not available. ) at /usr/src/sys/netinet/in.c:1380 #10 0xc0982470 in arpintr (m=0xc3baeb00) at /usr/src/sys/netinet/if_ether.c:642 #11 0xc094227a in netisr_dispatch_src (proto=7, source=0, m=0xc0de) at /usr/src/sys/net/netisr.c:932 #12 0xc09424dd in netisr_unregister (nhp=0xc0de) at /usr/src/sys/net/netisr.c:583 #13 0xc093ac69 in ether_demux (ifp=0x0, m=0xc3baeb00) at /usr/src/sys/net/if_ethersubr.c:911 #14 0xc093b1ce in ether_output (ifp=0xc36ad400, m=0xc3baeb00, dst=0xc0c55c27, ro=0x301010a) at /usr/src/sys/net/if_ethersubr.c:181 ---Type to continue, or q to quit--- #15 0xc070b032 in msk_handle_events (sc=0xc3686c00) at /usr/src/sys/dev/msk/if_msk.c:3048 #16 0xc070b828 in msk_int_task (arg=0xc3686c00, pending=1) at /usr/src/sys/dev/msk/if_msk.c:3625 #17 0xc08cac8c in taskqueue_run (queue=0xc36bf380) at /usr/src/sys/kern/subr_taskqueue.c:72 #18 0xc08cadcc in taskqueue_thread_loop (arg=0xc3686c8c) at /usr/src/sys/kern/subr_taskqueue.c:90 #19 0xc0869271 in fork_exit (callout=0xc08cad67 , arg=0xc3686c8c, frame=0xd533dd38) at /usr/src/sys/kern/kern_fork.c:854 #20 0xc0b8e520 in Xatpic_intr0 () at atpic_vector.s:62 #21 0x00000000 in ?? () Mark Atkinson wrote: > The following reply was made to PR kern/124127; it has been noted by GNATS. > > From: Mark Atkinson > To: freebsd prs > Cc: > Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering > Date: Wed, 28 Oct 2009 17:03:52 -0700 (PDT) From pyunyh at gmail.com Thu Oct 29 16:49:10 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Oct 29 16:49:16 2009 Subject: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering In-Reply-To: References: <200910290010.n9T0A3cV083541@freefall.freebsd.org> Message-ID: <20091029164909.GA13275@michelle.cdnetworks.com> On Thu, Oct 29, 2009 at 06:52:34AM -0700, Mark Atkinson wrote: > Wow, not sure what to blame for that charset nightmare. Apologies. > Here's the original message: > > On the unpatched -current kernel, built > > FreeBSD hellfire.filament.org 9.0-CURRENT FreeBSD 9.0-CURRENT #14: Mon > Oct 19 09:12:03 PDT 2009 > > I recieved the following panic today related to this: > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xdeadc10a > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0987410 > stack pointer = 0x28:0xd533dac0 > frame pointer = 0x28:0xd533dae8 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (mskc0 taskq) > Physical memory: 495 MB > Dumping 132 MB: 117 101 85 69 53 37 21 5 > > Reading symbols from /boot/kernel/linux.ko...Reading symbols from > /boot/kernel/linux.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/linux.ko > #0 0xc08907a9 in doadump () at /usr/src/sys/kern/kern_shutdown.c:254 > 254 } > (kgdb) bt > #0 0xc08907a9 in doadump () at /usr/src/sys/kern/kern_shutdown.c:254 > #1 0xc04f7e37 in db_fncall (dummy1=-1067299898, dummy2=0, > dummy3=-718022488, > dummy4=0xd533d898 "\200%t?") at /usr/src/sys/ddb/db_command.c:548 > #2 0xc04f8214 in db_command (last_cmdp=0xc0da059c, cmd_table=0x0, > dopager=1) > at /usr/src/sys/ddb/db_command.c:445 > #3 0xc04f8352 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 > #4 0xc04fa05e in db_trap (type=12, code=0) at > /usr/src/sys/ddb/db_main.c:229 > #5 0xc08bf2d2 in kdb_reenter () at /usr/src/sys/kern/subr_kdb.c:398 > #6 0xc0ba9b62 in trap_fatal (frame=0x1, eva=3735929098) > at /usr/src/sys/i386/i386/trap.c:938 > #7 0xc0baa483 in trap (frame=0xd533da80) at > /usr/src/sys/i386/i386/trap.c:339 > #8 0xc0b8e4ab in Xlcall_syscall () at > /usr/src/sys/i386/i386/exception.s:241 > #9 0xc0987410 in in_lltable_lookup (llt=0xc39e1000, flags=Variable > "flags" is not available. > ) > at /usr/src/sys/netinet/in.c:1380 > #10 0xc0982470 in arpintr (m=0xc3baeb00) at > /usr/src/sys/netinet/if_ether.c:642 > #11 0xc094227a in netisr_dispatch_src (proto=7, source=0, m=0xc0de) > at /usr/src/sys/net/netisr.c:932 > #12 0xc09424dd in netisr_unregister (nhp=0xc0de) > at /usr/src/sys/net/netisr.c:583 > #13 0xc093ac69 in ether_demux (ifp=0x0, m=0xc3baeb00) > at /usr/src/sys/net/if_ethersubr.c:911 > #14 0xc093b1ce in ether_output (ifp=0xc36ad400, m=0xc3baeb00, > dst=0xc0c55c27, > ro=0x301010a) at /usr/src/sys/net/if_ethersubr.c:181 > ---Type to continue, or q to quit--- > #15 0xc070b032 in msk_handle_events (sc=0xc3686c00) > at /usr/src/sys/dev/msk/if_msk.c:3048 > #16 0xc070b828 in msk_int_task (arg=0xc3686c00, pending=1) > at /usr/src/sys/dev/msk/if_msk.c:3625 > #17 0xc08cac8c in taskqueue_run (queue=0xc36bf380) > at /usr/src/sys/kern/subr_taskqueue.c:72 > #18 0xc08cadcc in taskqueue_thread_loop (arg=0xc3686c8c) > at /usr/src/sys/kern/subr_taskqueue.c:90 > #19 0xc0869271 in fork_exit (callout=0xc08cad67 , > arg=0xc3686c8c, frame=0xd533dd38) at /usr/src/sys/kern/kern_fork.c:854 > #20 0xc0b8e520 in Xatpic_intr0 () at atpic_vector.s:62 > #21 0x00000000 in ?? () > I think it's not a bug of msk(4). Qin Li fixed the bug in arp code. See r198301. For watchdog timeout issues on 88E8053 controller, did you ever try disabling MSI? msk(4) was changed a lot since 7.0-RELEASE to support newer controllers and added several workarounds to address silicon bugs. So don't blindly apply experimental patches to your controller. 88E8053 also has a couple of hardware bugs but I guess msk(4) already incorporated required workarounds. So if you can reliably reproduce watchdog timeouts please let me know. From pyunyh at gmail.com Thu Oct 29 16:50:03 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Oct 29 16:50:11 2009 Subject: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Message-ID: <200910291650.n9TGo2Nj087532@freefall.freebsd.org> The following reply was made to PR kern/124127; it has been noted by GNATS. From: Pyun YongHyeon To: Mark Atkinson Cc: freebsd-net@freebsd.org, bug-followup@FreeBSD.org Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Date: Thu, 29 Oct 2009 09:49:09 -0700 On Thu, Oct 29, 2009 at 06:52:34AM -0700, Mark Atkinson wrote: > Wow, not sure what to blame for that charset nightmare. Apologies. > Here's the original message: > > On the unpatched -current kernel, built > > FreeBSD hellfire.filament.org 9.0-CURRENT FreeBSD 9.0-CURRENT #14: Mon > Oct 19 09:12:03 PDT 2009 > > I recieved the following panic today related to this: > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xdeadc10a > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0987410 > stack pointer = 0x28:0xd533dac0 > frame pointer = 0x28:0xd533dae8 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (mskc0 taskq) > Physical memory: 495 MB > Dumping 132 MB: 117 101 85 69 53 37 21 5 > > Reading symbols from /boot/kernel/linux.ko...Reading symbols from > /boot/kernel/linux.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/linux.ko > #0 0xc08907a9 in doadump () at /usr/src/sys/kern/kern_shutdown.c:254 > 254 } > (kgdb) bt > #0 0xc08907a9 in doadump () at /usr/src/sys/kern/kern_shutdown.c:254 > #1 0xc04f7e37 in db_fncall (dummy1=-1067299898, dummy2=0, > dummy3=-718022488, > dummy4=0xd533d898 "\200%t?") at /usr/src/sys/ddb/db_command.c:548 > #2 0xc04f8214 in db_command (last_cmdp=0xc0da059c, cmd_table=0x0, > dopager=1) > at /usr/src/sys/ddb/db_command.c:445 > #3 0xc04f8352 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 > #4 0xc04fa05e in db_trap (type=12, code=0) at > /usr/src/sys/ddb/db_main.c:229 > #5 0xc08bf2d2 in kdb_reenter () at /usr/src/sys/kern/subr_kdb.c:398 > #6 0xc0ba9b62 in trap_fatal (frame=0x1, eva=3735929098) > at /usr/src/sys/i386/i386/trap.c:938 > #7 0xc0baa483 in trap (frame=0xd533da80) at > /usr/src/sys/i386/i386/trap.c:339 > #8 0xc0b8e4ab in Xlcall_syscall () at > /usr/src/sys/i386/i386/exception.s:241 > #9 0xc0987410 in in_lltable_lookup (llt=0xc39e1000, flags=Variable > "flags" is not available. > ) > at /usr/src/sys/netinet/in.c:1380 > #10 0xc0982470 in arpintr (m=0xc3baeb00) at > /usr/src/sys/netinet/if_ether.c:642 > #11 0xc094227a in netisr_dispatch_src (proto=7, source=0, m=0xc0de) > at /usr/src/sys/net/netisr.c:932 > #12 0xc09424dd in netisr_unregister (nhp=0xc0de) > at /usr/src/sys/net/netisr.c:583 > #13 0xc093ac69 in ether_demux (ifp=0x0, m=0xc3baeb00) > at /usr/src/sys/net/if_ethersubr.c:911 > #14 0xc093b1ce in ether_output (ifp=0xc36ad400, m=0xc3baeb00, > dst=0xc0c55c27, > ro=0x301010a) at /usr/src/sys/net/if_ethersubr.c:181 > ---Type to continue, or q to quit--- > #15 0xc070b032 in msk_handle_events (sc=0xc3686c00) > at /usr/src/sys/dev/msk/if_msk.c:3048 > #16 0xc070b828 in msk_int_task (arg=0xc3686c00, pending=1) > at /usr/src/sys/dev/msk/if_msk.c:3625 > #17 0xc08cac8c in taskqueue_run (queue=0xc36bf380) > at /usr/src/sys/kern/subr_taskqueue.c:72 > #18 0xc08cadcc in taskqueue_thread_loop (arg=0xc3686c8c) > at /usr/src/sys/kern/subr_taskqueue.c:90 > #19 0xc0869271 in fork_exit (callout=0xc08cad67 , > arg=0xc3686c8c, frame=0xd533dd38) at /usr/src/sys/kern/kern_fork.c:854 > #20 0xc0b8e520 in Xatpic_intr0 () at atpic_vector.s:62 > #21 0x00000000 in ?? () > I think it's not a bug of msk(4). Qin Li fixed the bug in arp code. See r198301. For watchdog timeout issues on 88E8053 controller, did you ever try disabling MSI? msk(4) was changed a lot since 7.0-RELEASE to support newer controllers and added several workarounds to address silicon bugs. So don't blindly apply experimental patches to your controller. 88E8053 also has a couple of hardware bugs but I guess msk(4) already incorporated required workarounds. So if you can reliably reproduce watchdog timeouts please let me know. From tom at tomjudge.com Thu Oct 29 17:30:48 2009 From: tom at tomjudge.com (Tom Judge) Date: Thu Oct 29 17:30:54 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: <4AE8CC59.7020004@tomjudge.com> References: <4AE72910.8090708@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B49180@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE76FF1.9010401@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B491AE@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE8CC59.7020004@tomjudge.com> Message-ID: <4AE9D10F.4040703@tomjudge.com> Tom Judge wrote: > David Christensen wrote: >>> Thanks for the rapid response. >>> >>> Dell have firmware 5.0.9 on their website here: http://tiny.cc/ex834 >>> >>> Will that work? >> >> Yes, that release does include a good version of BCM5709 bootcode >> (v5.06). >> I couldn't really tell until I downloaded the file and looked at the >> temporary files inside. Thanks for the link. >> >> > > After fighting with the update process for a bit and then learning about > the live cycle manager I have managed to test the R610 with the 5.0.9 > firmware. > > On the face of it, it seems that this resolves the issue. > After a reboot this morning the error has resurfaced and the box is again useless. Tom From atkin901 at yahoo.com Thu Oct 29 17:50:05 2009 From: atkin901 at yahoo.com (Mark Atkinson) Date: Thu Oct 29 17:50:12 2009 Subject: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Message-ID: <200910291750.n9THo5Fi038988@freefall.freebsd.org> The following reply was made to PR kern/124127; it has been noted by GNATS. From: Mark Atkinson To: pyunyh@gmail.com Cc: bug-followup@FreeBSD.org Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Date: Thu, 29 Oct 2009 10:47:47 -0700 (PDT) ----- Original Message ---- From: Pyun YongHyeon Sent: Thu, October 29, 2009 9:49:09 AM Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering >I think it's not a bug of msk(4). Qin Li fixed the bug in arp code. >See r198301. Thanks I saw the intr call in the trace and assumed wrong, the 'lltable' should have tipped me off. >For watchdog timeout issues on 88E8053 controller, did you ever try >disabling MSI? I haven't tried that lately in -current, last time I did that msk did not work at all. Will retry and report back. > msk(4) was changed a lot since 7.0-RELEASE to >support newer controllers and added several workarounds to address >silicon bugs. So don't blindly apply experimental patches to your >controller. Yes, this box runs -current constantly, only recently did I have to give up my dual Intel adapter and go back to using the on-board pci-e yukon, and thus re-experiencing this issue. > 88E8053 also has a couple of hardware bugs but I guess >msk(4) already incorporated required workarounds. So if you can >reliably reproduce watchdog timeouts please let me know. It still repros on -current, hence me trying out the experimental patches in the PR and reporting back. As I reported in this PR earlier I could still hit the watchdog after a week of runtime, but as of now I don't have a reliable repro. BTW thanks for all your hard work on hardware NIC support. Very much appreciated. From AStultz at datatekcorp.com Thu Oct 29 18:06:33 2009 From: AStultz at datatekcorp.com (Alan Stultz) Date: Thu Oct 29 18:06:39 2009 Subject: IPsec v3 question Message-ID: <00de01ca58c0$c0471710$ae01a8c0@datatekcorp.com> Hello All: I have a question about the implementation of IPsec version 3 in FreeBSD. We are porting from FreeBSD 5.4 to 7.2 and currently run an IPv6 application with IPsec version 2 and IKEv1 open source from the KAME group. Since the KAME group disbanded (around when 5.4 was released), I don't know what RFCs for IPsec and IPv6 are currently implemented in various FreeBSD releases. I'm most interested in the following: RFC4301 - Security Arch. for the Internet Protocol RFC4302 - IP Authentication Header RFC4303 - IP ESP RFC4308 - Cryptographic Suites for IPsec If anyone has a list or knowledge of the latest IPv6 RFCs supported in FreeBSD, I would appreciate any info on them. Thanks in advance, Alan From davidch at broadcom.com Thu Oct 29 18:12:34 2009 From: davidch at broadcom.com (David Christensen) Date: Thu Oct 29 18:12:40 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: <4AE9D10F.4040703@tomjudge.com> References: <4AE72910.8090708@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B49180@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE76FF1.9010401@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B491AE@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE8CC59.7020004@tomjudge.com> <4AE9D10F.4040703@tomjudge.com> Message-ID: <5D267A3F22FD854F8F48B3D2B52381933A054DE883@IRVEXCHCCR01.corp.ad.broadcom.com> > > After fighting with the update process for a bit and then learning > > about the live cycle manager I have managed to test the > R610 with the > > 5.0.9 firmware. > > > > On the face of it, it seems that this resolves the issue. > > > After a reboot this morning the error has resurfaced and the > box is again useless. Can you try a different test? Power-on the system with the network cable attached to an idle switch (i.e. keep all network traffic from being forwarded to the NIC during driver initialization). Does the system power up successfully? Repeatedly? The problem I saw was caused by network traffic being handled by the NIC during driver initialization. If you still see the same behavior then this might be a different issue. Dave From tom at tomjudge.com Thu Oct 29 20:06:07 2009 From: tom at tomjudge.com (Tom Judge) Date: Thu Oct 29 20:06:13 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: <5D267A3F22FD854F8F48B3D2B52381933A054DE883@IRVEXCHCCR01.corp.ad.broadcom.com> References: <4AE72910.8090708@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B49180@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE76FF1.9010401@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B491AE@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE8CC59.7020004@tomjudge.com> <4AE9D10F.4040703@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A054DE883@IRVEXCHCCR01.corp.ad.broadcom.com> Message-ID: <4AE9F576.4060101@tomjudge.com> David Christensen wrote: >>> After fighting with the update process for a bit and then learning >>> about the live cycle manager I have managed to test the >> R610 with the >>> 5.0.9 firmware. >>> >>> On the face of it, it seems that this resolves the issue. >>> >> After a reboot this morning the error has resurfaced and the >> box is again useless. > > Can you try a different test? Power-on the system with the network > cable attached to an idle switch (i.e. keep all network traffic from > being forwarded to the NIC during driver initialization). Does the > system power up successfully? Repeatedly? The problem I saw > was caused by network traffic being handled by the NIC during driver > initialization. If you still see the same behavior then this might > be a different issue. > Looks like we are heading in the right direction here. Setup: R610[bce1]->Netgear 100/10 unmanaged switch-[uplink]->Managed server access switch. The R610 is the only thing connected to the netgear switch. When the uplink was severed during boot up it was reconnected after the link up event and while the NFS mounts where being mounted. Cold reboots are with the server shutdown with the psu's remaining connected and then restarted. Warm are just 'shutdown -r now' Ice are from the psus disconnected from the mains supply. These results are time ordered. Type Uplink Result Warm No Works Warm No Works Warm No Works Cold No Works Warm No Works Cold No Works Warm No Works Ice No Works Warn No Works Ice Yes Works Warm Yes Works Cold Yes Works Warm Yes Works Ice Bybass Works Warm Bypass Fails Cold Bypass Works - paniced on shutdown spin lock (sched) held to long pid 0 Cold Bypass Works Warm Bypass Fails We can provide full remote access to the following hardware (via enterprise drac) if required and on site hands if this will help get this issue resolved. 3 * R610 4 * R410 7 * R710 Tom From davidch at broadcom.com Thu Oct 29 20:40:49 2009 From: davidch at broadcom.com (David Christensen) Date: Thu Oct 29 20:40:56 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: <4AE9F576.4060101@tomjudge.com> References: <4AE72910.8090708@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B49180@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE76FF1.9010401@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B491AE@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE8CC59.7020004@tomjudge.com> <4AE9D10F.4040703@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A054DE883@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE9F576.4060101@tomjudge.com> Message-ID: <5D267A3F22FD854F8F48B3D2B52381933A19B35A55@IRVEXCHCCR01.corp.ad.broadcom.com> > > Can you try a different test? Power-on the system with the network > > cable attached to an idle switch (i.e. keep all network > traffic from > > being forwarded to the NIC during driver initialization). Does the > > system power up successfully? Repeatedly? The problem I saw was > > caused by network traffic being handled by the NIC during driver > > initialization. If you still see the same behavior then > this might be > > a different issue. > > > > Looks like we are heading in the right direction here. > The next test is to diable the LOM's management firmware but boot to an active network. Get the User Diag utility at the bottom of http://www.broadcom.com/support/ethernet_nic/netxtremeii.php. Run the uxdiag utility with the command line: "C:\>uxdiag -c 0 -mfw 0 -c 1 -mfw 0 -c 2 -mfw 0 -c 3 mfw 0" The "-c X" specifies with LOM to use while the "-mfw 0" disables the firmware. Use the appropriate number of "-c X" values for the number of ports on your system (the r710 has 4 ports). To re-enable the firmware do the following: "C:\>uxdiag -c 0 -mfw 1 -c 1 -mfw 1 -c 2 -mfw 1 -c 3 mfw 1" Finally, the routine bce_print_adapter_info() in HEAD prints out both the bootcode and management firmware versions. If you can get those same changes into your release I'd like to see the versions reported on your system. Dave From tom at tomjudge.com Thu Oct 29 21:38:18 2009 From: tom at tomjudge.com (Tom Judge) Date: Thu Oct 29 21:39:08 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: <5D267A3F22FD854F8F48B3D2B52381933A19B35A55@IRVEXCHCCR01.corp.ad.broadcom.com> References: <4AE72910.8090708@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B49180@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE76FF1.9010401@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B491AE@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE8CC59.7020004@tomjudge.com> <4AE9D10F.4040703@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A054DE883@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE9F576.4060101@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35A55@IRVEXCHCCR01.corp.ad.broadcom.com> Message-ID: <4AEA0B11.2050209@tomjudge.com> David Christensen wrote: >>> Can you try a different test? Power-on the system with the network >>> cable attached to an idle switch (i.e. keep all network >> traffic from >>> being forwarded to the NIC during driver initialization). Does the >>> system power up successfully? Repeatedly? The problem I saw was >>> caused by network traffic being handled by the NIC during driver >>> initialization. If you still see the same behavior then >> this might be >>> a different issue. >>> >> Looks like we are heading in the right direction here. >> > > > The next test is to diable the LOM's management firmware but boot to > an active network. Get the User Diag utility at the bottom of > http://www.broadcom.com/support/ethernet_nic/netxtremeii.php. > Run the uxdiag utility with the command line: > "C:\>uxdiag -c 0 -mfw 0 -c 1 -mfw 0 -c 2 -mfw 0 -c 3 mfw 0" > The "-c X" specifies with LOM to use while the "-mfw 0" disables > the firmware. Use the appropriate number of "-c X" values for > the number of ports on your system (the r710 has 4 ports). > To re-enable the firmware do the following: > "C:\>uxdiag -c 0 -mfw 1 -c 1 -mfw 1 -c 2 -mfw 1 -c 3 mfw 1" > > Finally, the routine bce_print_adapter_info() in HEAD prints out both > the bootcode and management firmware versions. If you can get those > same changes into your release I'd like to see the versions reported > on your system. > Here is the info from a boot of 8.0 RC2. ASIC: 0x57092003 B/C: 5.0.6 Rev: C0 Bus: PCIe x4, 2.5Gb/s Flags: MSI|MFW MFW: NCS 2.0.3 And looking at this it seems dells update CD was not up to date enough and I only got 5.0.6 firmware not 5.0.9. I will update this now and retest. TJ From davidch at broadcom.com Thu Oct 29 21:52:51 2009 From: davidch at broadcom.com (David Christensen) Date: Thu Oct 29 21:52:59 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: <4AEA0B11.2050209@tomjudge.com> References: <4AE72910.8090708@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B49180@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE76FF1.9010401@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B491AE@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE8CC59.7020004@tomjudge.com> <4AE9D10F.4040703@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A054DE883@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE9F576.4060101@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35A55@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA0B11.2050209@tomjudge.com> Message-ID: <5D267A3F22FD854F8F48B3D2B52381933A19B35AB0@IRVEXCHCCR01.corp.ad.broadcom.com> > > The next test is to diable the LOM's management firmware > but boot to > > an active network. Get the User Diag utility at the bottom of > > http://www.broadcom.com/support/ethernet_nic/netxtremeii.php. > > Run the uxdiag utility with the command line: > > "C:\>uxdiag -c 0 -mfw 0 -c 1 -mfw 0 -c 2 -mfw 0 -c 3 mfw 0" > > The "-c X" specifies with LOM to use while the "-mfw 0" > disables the > > firmware. Use the appropriate number of "-c X" values for > the number > > of ports on your system (the r710 has 4 ports). > > To re-enable the firmware do the following: > > "C:\>uxdiag -c 0 -mfw 1 -c 1 -mfw 1 -c 2 -mfw 1 -c 3 mfw 1" > > > > Finally, the routine bce_print_adapter_info() in HEAD > prints out both > > the bootcode and management firmware versions. If you can > get those > > same changes into your release I'd like to see the versions > reported > > on your system. > > > > Here is the info from a boot of 8.0 RC2. > > ASIC: 0x57092003 > B/C: 5.0.6 > Rev: C0 > Bus: PCIe x4, 2.5Gb/s > Flags: MSI|MFW > MFW: NCS 2.0.3 > > And looking at this it seems dells update CD was not up to > date enough and I only got 5.0.6 firmware not 5.0.9. The package version and the bootcode version are similar but they are not the same. The bootcode you have (v5.0.6) is sufficient to fix the problem. Dave From tom at tomjudge.com Thu Oct 29 22:05:48 2009 From: tom at tomjudge.com (Tom Judge) Date: Thu Oct 29 22:05:54 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: <5D267A3F22FD854F8F48B3D2B52381933A19B35AB0@IRVEXCHCCR01.corp.ad.broadcom.com> References: <4AE72910.8090708@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B49180@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE76FF1.9010401@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B491AE@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE8CC59.7020004@tomjudge.com> <4AE9D10F.4040703@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A054DE883@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE9F576.4060101@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35A55@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA0B11.2050209@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35AB0@IRVEXCHCCR01.corp.ad.broadcom.com> Message-ID: <4AEA1183.7050306@tomjudge.com> David Christensen wrote: >>> The next test is to diable the LOM's management firmware >> but boot to >>> an active network. Get the User Diag utility at the bottom of >>> http://www.broadcom.com/support/ethernet_nic/netxtremeii.php. >>> Run the uxdiag utility with the command line: >>> "C:\>uxdiag -c 0 -mfw 0 -c 1 -mfw 0 -c 2 -mfw 0 -c 3 mfw 0" >>> The "-c X" specifies with LOM to use while the "-mfw 0" >> disables the >>> firmware. Use the appropriate number of "-c X" values for >> the number >>> of ports on your system (the r710 has 4 ports). >>> To re-enable the firmware do the following: >>> "C:\>uxdiag -c 0 -mfw 1 -c 1 -mfw 1 -c 2 -mfw 1 -c 3 mfw 1" >>> >>> Finally, the routine bce_print_adapter_info() in HEAD >> prints out both >>> the bootcode and management firmware versions. If you can >> get those >>> same changes into your release I'd like to see the versions >> reported >>> on your system. >>> >> Here is the info from a boot of 8.0 RC2. >> >> ASIC: 0x57092003 >> B/C: 5.0.6 >> Rev: C0 >> Bus: PCIe x4, 2.5Gb/s >> Flags: MSI|MFW >> MFW: NCS 2.0.3 >> >> And looking at this it seems dells update CD was not up to >> date enough and I only got 5.0.6 firmware not 5.0.9. > > The package version and the bootcode version are similar but > they are not the same. The bootcode you have (v5.0.6) is > sufficient to fix the problem. > Ok just checked in the life cycle manager and it has 5.0.9 installed my bad. Running the other test now. Tom From bschmidt at techwires.net Fri Oct 30 08:26:50 2009 From: bschmidt at techwires.net (Bernhard Schmidt) Date: Fri Oct 30 08:26:57 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <200910251024.06856.bschmidt@techwires.net> References: <20091009170839.142800@gmx.net> <11167f520910241241o6a1ada3cmf076add6374a1add@mail.gmail.com> <200910251024.06856.bschmidt@techwires.net> Message-ID: <200910300926.32286.bschmidt@techwires.net> On Sunday 25 October 2009 10:24:06 Bernhard Schmidt wrote: > On Saturday 24 October 2009 21:41:39 Sam Fourman Jr. wrote: > > Just wanted to make everyone aware that OpenBSD just 1 hour ago commited > > a bunch of changes to their iwn driver. maybe some of it is useful for > > FreeBSD as well? > > Definitely, I'll look into that. Another update: * ICT interrupts for 5000/6000 series * New firmware * Initial support for 1000 series and initial bits for upcoming 6000 series (untested as hardware is not available to the general public) * Many bug fixes, including workarounds for hardware bugs * Addresses kern/140036 Most of this stuff has been obtained from OpeBSD. Testes/Feedback welcome! http://techwires.net/~bschmidt/patches/freebsd/iwn/iwn_merge_20081028.diff.bz2 -- Bernhard From tom at tomjudge.com Fri Oct 30 17:43:07 2009 From: tom at tomjudge.com (Tom Judge) Date: Fri Oct 30 17:43:13 2009 Subject: bce(4) BCM5907 CTX write errors on 7.2 driver In-Reply-To: <4AEA1183.7050306@tomjudge.com> References: <4AE72910.8090708@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B49180@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE76FF1.9010401@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B491AE@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE8CC59.7020004@tomjudge.com> <4AE9D10F.4040703@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A054DE883@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE9F576.4060101@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35A55@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA0B11.2050209@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35AB0@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA1183.7050306@tomjudge.com> Message-ID: <4AEB2571.7090006@tomjudge.com> Tom Judge wrote: > David Christensen wrote: >>>> The next test is to diable the LOM's management firmware >>> but boot to >>>> an active network. After disabling the management firmware and doing 1 cold reboot and 3 warms all worked correctly. After re enabling the firmware and doing 1 cold reboot and 3 warms, the cold works correctly and the warms all failed. Tom >>>> Finally, the routine bce_print_adapter_info() in HEAD >>> prints out both >>>> the bootcode and management firmware versions. If you can >>> get those >>>> same changes into your release I'd like to see the versions >>> reported >>>> on your system. >>>> >>> Here is the info from a boot of 8.0 RC2. >>> >>> ASIC: 0x57092003 >>> B/C: 5.0.6 >>> Rev: C0 >>> Bus: PCIe x4, 2.5Gb/s >>> Flags: MSI|MFW >>> MFW: NCS 2.0.3 >>> >>> And looking at this it seems dells update CD was not up to date >>> enough and I only got 5.0.6 firmware not 5.0.9. >> >> The package version and the bootcode version are similar but >> they are not the same. The bootcode you have (v5.0.6) is >> sufficient to fix the problem. >> > > Ok just checked in the life cycle manager and it has 5.0.9 installed my > bad. > > Running the other test now. > From sh at keff.org Fri Oct 30 22:05:23 2009 From: sh at keff.org (Sebastian Hyrwall) Date: Fri Oct 30 22:05:30 2009 Subject: Hi. /31 on ethernet links Message-ID: <4AEB7AE8.5090101@keff.org> Hi. Is there any way to use /31's on ordinary ethernet links in 7.2? "ifconfig addr dest-addr" does not work either. It keeps setting the last ip as broadcast. Sincerley, Sebastian H From sh at keff.org Fri Oct 30 22:20:52 2009 From: sh at keff.org (Sebastian Hyrwall) Date: Fri Oct 30 22:20:59 2009 Subject: Hi. /31 on ethernet links In-Reply-To: <18C758A7-1908-4D1A-BDCA-80FF7FD8BC22@mac.com> References: <4AEB7AE8.5090101@keff.org> <18C758A7-1908-4D1A-BDCA-80FF7FD8BC22@mac.com> Message-ID: <4AEB834D.1050907@keff.org> Chuck Swiger skrev: > On Oct 30, 2009, at 4:46 PM, Sebastian Hyrwall wrote: >> Is there any way to use /31's on ordinary ethernet links in 7.2? >> "ifconfig addr dest-addr" does not work either. It keeps setting the >> last ip as broadcast. > > A /31 subnet is only defined for point-to-point network links, per: > > http://www.rfc-editor.org/rfc/rfc3021.txt > > Ordinary ethernet links have BROADCAST flag set instead of POINTOPOINT. > > Regards, Well how do I set the POINTOPOINT flag and remove the BROADCAST-flag on ethernet links? Or are you implying that it does not belong on ethernet links :) Cause Cisco and Linux support /31 (ptp's) on ordinary ethernet links. Sincerely, Sebastian H From sh at keff.org Fri Oct 30 22:27:37 2009 From: sh at keff.org (Sebastian Hyrwall) Date: Fri Oct 30 22:27:43 2009 Subject: Hi. /31 on ethernet links In-Reply-To: References: <4AEB7AE8.5090101@keff.org> <18C758A7-1908-4D1A-BDCA-80FF7FD8BC22@mac.com> <4AEB834D.1050907@keff.org> Message-ID: <4AEB84E3.1070908@keff.org> Freddie Cash skrev: > Reading the man page for ifconfig will show the "ptp" option for > ifconfig, that configures the interface as a point-to-point > interface.. :) > It will also show that it seems to be only for bridgeing, # ifconfig fxp0 ptp fxp0 ifconfig: unable to get bridge flags: Invalid argument > > > On Fri, Oct 30, 2009 at 5:22 PM, Sebastian Hyrwall > wrote: > > Chuck Swiger skrev: > > On Oct 30, 2009, at 4:46 PM, Sebastian Hyrwall wrote: > > Is there any way to use /31's on ordinary ethernet links > in 7.2? "ifconfig addr dest-addr" does not work either. It > keeps setting the last ip as broadcast. > > > A /31 subnet is only defined for point-to-point network links, > per: > > http://www.rfc-editor.org/rfc/rfc3021.txt > > Ordinary ethernet links have BROADCAST flag set instead of > POINTOPOINT. > > Regards, > > Well how do I set the POINTOPOINT flag and remove the > BROADCAST-flag on ethernet links? Or are you implying that it does > not belong on ethernet links :) > Cause Cisco and Linux support /31 (ptp's) on ordinary ethernet links. > > Sincerely, > > Sebastian H > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org > " > > > > > -- > Freddie Cash > fjwcash@gmail.com From cswiger at mac.com Fri Oct 30 22:37:26 2009 From: cswiger at mac.com (Chuck Swiger) Date: Fri Oct 30 22:37:32 2009 Subject: Hi. /31 on ethernet links In-Reply-To: <4AEB834D.1050907@keff.org> References: <4AEB7AE8.5090101@keff.org> <18C758A7-1908-4D1A-BDCA-80FF7FD8BC22@mac.com> <4AEB834D.1050907@keff.org> Message-ID: On Oct 30, 2009, at 5:22 PM, Sebastian Hyrwall wrote: >> A /31 subnet is only defined for point-to-point network links, per: >> >> http://www.rfc-editor.org/rfc/rfc3021.txt >> >> Ordinary ethernet links have BROADCAST flag set instead of >> POINTOPOINT. >> > > Well how do I set the POINTOPOINT flag and remove the BROADCAST-flag > on ethernet links? Or are you implying that it does not belong on > ethernet links :) Cause Cisco and Linux support /31 (ptp's) on > ordinary ethernet links. Ethernet point-to-point links are normally handled by ppp / pppd in PPPoE mode, but possibly something like: ifconfig en0 inet 192.1.1.10 inet 192.1.1.2 ...would give you a POINTOPOINT link instead. If not, you can probably fake things out by either using a /30 and wrapping the /31 inside, or using a /32 and an explicit default route via your ethernet interface. Regards, -- -Chuck From cswiger at mac.com Fri Oct 30 22:43:48 2009 From: cswiger at mac.com (Chuck Swiger) Date: Fri Oct 30 22:43:54 2009 Subject: Hi. /31 on ethernet links In-Reply-To: References: <4AEB7AE8.5090101@keff.org> <18C758A7-1908-4D1A-BDCA-80FF7FD8BC22@mac.com> <4AEB834D.1050907@keff.org> Message-ID: On Oct 30, 2009, at 3:37 PM, Chuck Swiger wrote: > ifconfig en0 inet 192.1.1.10 inet 192.1.1.2 Whoops-- copy-paste-typo; instead should be: ifconfig en0 inet 192.1.1.10 192.1.1.11 -- -Chuck From fjwcash at gmail.com Fri Oct 30 22:53:04 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Fri Oct 30 22:53:11 2009 Subject: Hi. /31 on ethernet links In-Reply-To: <4AEB834D.1050907@keff.org> References: <4AEB7AE8.5090101@keff.org> <18C758A7-1908-4D1A-BDCA-80FF7FD8BC22@mac.com> <4AEB834D.1050907@keff.org> Message-ID: Reading the man page for ifconfig will show the "ptp" option for ifconfig, that configures the interface as a point-to-point interface.. :) On Fri, Oct 30, 2009 at 5:22 PM, Sebastian Hyrwall wrote: > Chuck Swiger skrev: > >> On Oct 30, 2009, at 4:46 PM, Sebastian Hyrwall wrote: >> >>> Is there any way to use /31's on ordinary ethernet links in 7.2? >>> "ifconfig addr dest-addr" does not work either. It keeps setting the last ip >>> as broadcast. >>> >> >> A /31 subnet is only defined for point-to-point network links, per: >> >> http://www.rfc-editor.org/rfc/rfc3021.txt >> >> Ordinary ethernet links have BROADCAST flag set instead of POINTOPOINT. >> >> Regards, >> > Well how do I set the POINTOPOINT flag and remove the BROADCAST-flag on > ethernet links? Or are you implying that it does not belong on ethernet > links :) > Cause Cisco and Linux support /31 (ptp's) on ordinary ethernet links. > > Sincerely, > > Sebastian H > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Freddie Cash fjwcash@gmail.com From cswiger at mac.com Fri Oct 30 23:12:42 2009 From: cswiger at mac.com (Chuck Swiger) Date: Fri Oct 30 23:12:48 2009 Subject: Hi. /31 on ethernet links In-Reply-To: <4AEB7AE8.5090101@keff.org> References: <4AEB7AE8.5090101@keff.org> Message-ID: <18C758A7-1908-4D1A-BDCA-80FF7FD8BC22@mac.com> On Oct 30, 2009, at 4:46 PM, Sebastian Hyrwall wrote: > Is there any way to use /31's on ordinary ethernet links in 7.2? > "ifconfig addr dest-addr" does not work either. It keeps setting the > last ip as broadcast. A /31 subnet is only defined for point-to-point network links, per: http://www.rfc-editor.org/rfc/rfc3021.txt Ordinary ethernet links have BROADCAST flag set instead of POINTOPOINT. Regards, -- -Chuck From sh at keff.org Fri Oct 30 23:19:47 2009 From: sh at keff.org (Sebastian Hyrwall) Date: Fri Oct 30 23:19:54 2009 Subject: Hi. /31 on ethernet links In-Reply-To: References: <4AEB7AE8.5090101@keff.org> <18C758A7-1908-4D1A-BDCA-80FF7FD8BC22@mac.com> <4AEB834D.1050907@keff.org> Message-ID: <4AEB911E.1070104@keff.org> Chuck Swiger skrev: > On Oct 30, 2009, at 5:22 PM, Sebastian Hyrwall wrote: >>> A /31 subnet is only defined for point-to-point network links, per: >>> >>> http://www.rfc-editor.org/rfc/rfc3021.txt >>> >>> Ordinary ethernet links have BROADCAST flag set instead of POINTOPOINT. >>> >> >> Well how do I set the POINTOPOINT flag and remove the BROADCAST-flag >> on ethernet links? Or are you implying that it does not belong on >> ethernet links :) Cause Cisco and Linux support /31 (ptp's) on >> ordinary ethernet links. > > Ethernet point-to-point links are normally handled by ppp / pppd in > PPPoE mode, but possibly something like: > > ifconfig en0 inet 192.1.1.10 inet 192.1.1.2 > > ...would give you a POINTOPOINT link instead. If not, you can > probably fake things out by either using a /30 and wrapping the /31 > inside, or using a /32 and an explicit default route via your > ethernet interface. > Unfortunetly that doesn't work. It just sets 192.1.1.2 as broadcast. Well wrapping a /31 inside of a /30 kinda defeats the purpose :) If Cisco,Linux and NetBSD support it so should FreeBSD imho. > Regards, From lstewart at freebsd.org Sat Oct 31 01:03:06 2009 From: lstewart at freebsd.org (Lawrence Stewart) Date: Sat Oct 31 01:03:13 2009 Subject: WPI panic (was: Can we turn off WPI_DEBUG) In-Reply-To: <4AE77437.4090700@FreeBSD.org> References: <4AE77437.4090700@FreeBSD.org> Message-ID: <4AEB8CBC.5050705@freebsd.org> Doug Barton wrote: > I cc'ed those who seem to have put the most/recent effort into > sys/dev/wpi. > > Is there any objection to turning off WPI_DEBUG by default? it creates > a lot of spam that the average user doesn't need. I use my 3945abg > every day and haven't had any problems with it for ages so I think > it's safe to say we're out of the period were debug by default is needed? Doug, have you ever experienced the issue with your 3945 card that I reported here: http://lists.freebsd.org/pipermail/freebsd-net/2009-October/023348.html I'm guessing you haven't by your comment about lack of problems. Do you run with INVARIANTS in your kernel? Cheers, Lawrence From dougb at FreeBSD.org Sat Oct 31 01:22:16 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sat Oct 31 01:22:22 2009 Subject: WPI panic In-Reply-To: <4AEB8CBC.5050705@freebsd.org> References: <4AE77437.4090700@FreeBSD.org> <4AEB8CBC.5050705@freebsd.org> Message-ID: <4AEB9150.1040304@FreeBSD.org> Lawrence Stewart wrote: > Doug Barton wrote: >> I cc'ed those who seem to have put the most/recent effort into >> sys/dev/wpi. >> >> Is there any objection to turning off WPI_DEBUG by default? it creates >> a lot of spam that the average user doesn't need. I use my 3945abg >> every day and haven't had any problems with it for ages so I think >> it's safe to say we're out of the period were debug by default is needed? > > Doug, have you ever experienced the issue with your 3945 card that I > reported here: > > http://lists.freebsd.org/pipermail/freebsd-net/2009-October/023348.html > > I'm guessing you haven't by your comment about lack of problems. No, I have not had those problems at all. I routinely associate with both WPA and WPA2 routers, as well as open routers at coffee shops and such. > Do you run with INVARIANTS in your kernel? Yes, and up till recently I've been running with witness as well. Wish I could be more help, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From randy at psg.com Sat Oct 31 01:32:00 2009 From: randy at psg.com (Randy Bush) Date: Sat Oct 31 01:32:06 2009 Subject: Hi. /31 on ethernet links In-Reply-To: <18C758A7-1908-4D1A-BDCA-80FF7FD8BC22@mac.com> References: <4AEB7AE8.5090101@keff.org> <18C758A7-1908-4D1A-BDCA-80FF7FD8BC22@mac.com> Message-ID: /31 on point to point ether is exceedingly common in inter-router topologies. you may be amused to also read draft-kohno-ipv6-prefixlen-p2p-00.txt randy From sthaug at nethelp.no Sat Oct 31 08:01:55 2009 From: sthaug at nethelp.no (sthaug@nethelp.no) Date: Sat Oct 31 08:02:11 2009 Subject: Hi. /31 on ethernet links In-Reply-To: <4AEB834D.1050907@keff.org> References: <4AEB7AE8.5090101@keff.org> <18C758A7-1908-4D1A-BDCA-80FF7FD8BC22@mac.com> <4AEB834D.1050907@keff.org> Message-ID: <20091031.090152.74670981.sthaug@nethelp.no> > > A /31 subnet is only defined for point-to-point network links, per: > > > > http://www.rfc-editor.org/rfc/rfc3021.txt > > > > Ordinary ethernet links have BROADCAST flag set instead of POINTOPOINT. > > > > Regards, > Well how do I set the POINTOPOINT flag and remove the BROADCAST-flag on > ethernet links? Or are you implying that it does not belong on ethernet > links :) > Cause Cisco and Linux support /31 (ptp's) on ordinary ethernet links. No, Cisco does not *support* it. They make it available, which is a completely different story. We have asked Cisco repeatedly, through official channels, whether they *support* /31 on Ethernet links. The answer is always that it *may* work, use at your own peril. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From randy at psg.com Sat Oct 31 09:56:44 2009 From: randy at psg.com (Randy Bush) Date: Sat Oct 31 09:56:51 2009 Subject: Hi. /31 on ethernet links In-Reply-To: <20091031.090152.74670981.sthaug@nethelp.no> References: <4AEB7AE8.5090101@keff.org> <18C758A7-1908-4D1A-BDCA-80FF7FD8BC22@mac.com> <4AEB834D.1050907@keff.org> <20091031.090152.74670981.sthaug@nethelp.no> Message-ID: > No, Cisco does not *support* it. They make it available, which is a > completely different story. > > We have asked Cisco repeatedly, through official channels, whether > they *support* /31 on Ethernet links. The answer is always that it > *may* work, use at your own peril. i have managed O(10^3) ciscos in isp backbone(s). /31s predominate for ether links in that space. though i suspect there is more multipoint in the enterprise space. we need to be able to use /31s and /127s on freebsd if it is to be used in the routing space. randy From sthaug at nethelp.no Sat Oct 31 10:08:39 2009 From: sthaug at nethelp.no (sthaug@nethelp.no) Date: Sat Oct 31 10:08:51 2009 Subject: Hi. /31 on ethernet links In-Reply-To: References: <4AEB834D.1050907@keff.org> <20091031.090152.74670981.sthaug@nethelp.no> Message-ID: <20091031.110837.41706473.sthaug@nethelp.no> > > We have asked Cisco repeatedly, through official channels, whether > > they *support* /31 on Ethernet links. The answer is always that it > > *may* work, use at your own peril. > > i have managed O(10^3) ciscos in isp backbone(s). /31s predominate for > ether links in that space. though i suspect there is more multipoint in > the enterprise space. > > we need to be able to use /31s and /127s on freebsd if it is to be used > in the routing space. I agree about that. However, I was simply reacting to the claim that it was *supported* by Cisco. We have asked both Cisco and Juniper, and neither company is willing to state that it is *supported*. Our Ethernet core links are /30 for IPv4 and /124 for IPv6. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From randy at psg.com Sat Oct 31 10:41:28 2009 From: randy at psg.com (Randy Bush) Date: Sat Oct 31 10:41:35 2009 Subject: Hi. /31 on ethernet links In-Reply-To: <20091031.110837.41706473.sthaug@nethelp.no> References: <4AEB834D.1050907@keff.org> <20091031.090152.74670981.sthaug@nethelp.no> <20091031.110837.41706473.sthaug@nethelp.no> Message-ID: > However, I was simply reacting to the claim that it was *supported* by > Cisco. have you noticed a difference in the bug rate between things that are 'supported by cisco' and those that just happen to be there? :) but you're right. i liked. our p2ps are /30s, not /31s. and we're moving from /126 to /127. randy From nvass9573 at gmx.com Sat Oct 31 11:42:25 2009 From: nvass9573 at gmx.com (Nikos Vassiliadis) Date: Sat Oct 31 11:42:32 2009 Subject: Hi. /31 on ethernet links In-Reply-To: <4AEB911E.1070104@keff.org> References: <4AEB7AE8.5090101@keff.org> <18C758A7-1908-4D1A-BDCA-80FF7FD8BC22@mac.com> <4AEB834D.1050907@keff.org> <4AEB911E.1070104@keff.org> Message-ID: <4AEC2297.40805@gmx.com> Sebastian Hyrwall wrote: > Chuck Swiger skrev: >> inside, or using a /32 and an explicit default route via your >> ethernet interface. >> > Unfortunetly that doesn't work. It just sets 192.1.1.2 as broadcast. > > Well wrapping a /31 inside of a /30 kinda defeats the purpose :) > You could still use a /32 and then add a route for the other IP via the ethernet interface. This is effectively the same with a /31. From sh at keff.org Sat Oct 31 13:35:17 2009 From: sh at keff.org (Sebastian Hyrwall) Date: Sat Oct 31 13:35:26 2009 Subject: Hi. /31 on ethernet links In-Reply-To: <4AEC2297.40805@gmx.com> References: <4AEB7AE8.5090101@keff.org> <18C758A7-1908-4D1A-BDCA-80FF7FD8BC22@mac.com> <4AEB834D.1050907@keff.org> <4AEB911E.1070104@keff.org> <4AEC2297.40805@gmx.com> Message-ID: <4AEC599F.90202@keff.org> Nikos Vassiliadis skrev: > Sebastian Hyrwall wrote: >> Chuck Swiger skrev: >>> inside, or using a /32 and an explicit default route via your >>> ethernet interface. >>> >> Unfortunetly that doesn't work. It just sets 192.1.1.2 as broadcast. >> >> Well wrapping a /31 inside of a /30 kinda defeats the purpose :) >> > > You could still use a /32 and then add a route for the other IP via > the ethernet interface. This is effectively the same with a /31. > Does not work, # ifconfig re0.212 172.16.25.10 netmask 255.255.255.255 # route add 172.16.25.11 -iface re0.212 add host 172.16.25.11: gateway re0.212 # ping 172.16.25.11 36 bytes from 172.16.25.10: Redirect Host(New addr: 172.16.25.11) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 bdbb 0 0000 40 01 0000 172.16.25.10 172.16.25.11 From jamesbrandongooch at gmail.com Sat Oct 31 15:42:34 2009 From: jamesbrandongooch at gmail.com (Brandon Gooch) Date: Sat Oct 31 15:42:40 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <200910300926.32286.bschmidt@techwires.net> References: <20091009170839.142800@gmx.net> <11167f520910241241o6a1ada3cmf076add6374a1add@mail.gmail.com> <200910251024.06856.bschmidt@techwires.net> <200910300926.32286.bschmidt@techwires.net> Message-ID: <179b97fb0910310842o63b48746r9380e4bf29cdc856@mail.gmail.com> On Fri, Oct 30, 2009 at 8:26 AM, Bernhard Schmidt wrote: > On Sunday 25 October 2009 10:24:06 Bernhard Schmidt wrote: >> On Saturday 24 October 2009 21:41:39 Sam Fourman Jr. wrote: >> > Just wanted to make everyone aware that OpenBSD just 1 hour ago commited >> > a bunch of changes to their iwn driver. maybe some of it is useful for >> > FreeBSD as well? >> >> Definitely, I'll look into that. > > Another update: > > * ICT interrupts for 5000/6000 series > * New firmware > * Initial support for 1000 series and initial bits for upcoming 6000 ?series > (untested as hardware is not available to the general public) > * Many bug fixes, including workarounds for hardware bugs > * Addresses kern/140036 > > Most of this stuff has been obtained from OpeBSD. Testes/Feedback welcome! > > http://techwires.net/~bschmidt/patches/freebsd/iwn/iwn_merge_20081028.diff.bz2 > > -- > Bernhard This is working VERY well with my 4965. I haven't had a single issue with stability, no firmware errors, I associate with APs much more quickly, and it's measurably faster. Thanks for all of your hard work Bernhard! Hope we see this in the tree soon... -Brandon From jamesbrandongooch at gmail.com Sat Oct 31 16:01:47 2009 From: jamesbrandongooch at gmail.com (Brandon Gooch) Date: Sat Oct 31 16:01:53 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <200910300926.32286.bschmidt@techwires.net> References: <20091009170839.142800@gmx.net> <11167f520910241241o6a1ada3cmf076add6374a1add@mail.gmail.com> <200910251024.06856.bschmidt@techwires.net> <200910300926.32286.bschmidt@techwires.net> Message-ID: <179b97fb0910310901tf8686b1u87a21c3408c93471@mail.gmail.com> On Fri, Oct 30, 2009 at 8:26 AM, Bernhard Schmidt wrote: > On Sunday 25 October 2009 10:24:06 Bernhard Schmidt wrote: >> On Saturday 24 October 2009 21:41:39 Sam Fourman Jr. wrote: >> > Just wanted to make everyone aware that OpenBSD just 1 hour ago commited >> > a bunch of changes to their iwn driver. maybe some of it is useful for >> > FreeBSD as well? >> >> Definitely, I'll look into that. > > Another update: > > * ICT interrupts for 5000/6000 series > * New firmware > * Initial support for 1000 series and initial bits for upcoming 6000 ?series > (untested as hardware is not available to the general public) > * Many bug fixes, including workarounds for hardware bugs > * Addresses kern/140036 > > Most of this stuff has been obtained from OpeBSD. Testes/Feedback welcome! > > http://techwires.net/~bschmidt/patches/freebsd/iwn/iwn_merge_20081028.diff.bz2 > > -- > Bernhard This is working VERY well with my 4965. In fact, I haven't had a single issue with stability, I associate with APs much more quickly, and it's measurably faster. Thanks Bernhard From freebsd at levsha.org.ua Sat Oct 31 17:46:18 2009 From: freebsd at levsha.org.ua (Mykola Dzham) Date: Sat Oct 31 17:46:25 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <200910300926.32286.bschmidt@techwires.net> References: <20091009170839.142800@gmx.net> <11167f520910241241o6a1ada3cmf076add6374a1add@mail.gmail.com> <200910251024.06856.bschmidt@techwires.net> <200910300926.32286.bschmidt@techwires.net> Message-ID: <20091031174631.GA32588@expo.ukrweb.net> Bernhard Schmidt wrote: > On Sunday 25 October 2009 10:24:06 Bernhard Schmidt wrote: > > On Saturday 24 October 2009 21:41:39 Sam Fourman Jr. wrote: > > > Just wanted to make everyone aware that OpenBSD just 1 hour ago commited > > > a bunch of changes to their iwn driver. maybe some of it is useful for > > > FreeBSD as well? > > > > Definitely, I'll look into that. > > Another update: > > * ICT interrupts for 5000/6000 series > * New firmware > * Initial support for 1000 series and initial bits for upcoming 6000 series > (untested as hardware is not available to the general public) > * Many bug fixes, including workarounds for hardware bugs > * Addresses kern/140036 > > Most of this stuff has been obtained from OpeBSD. Testes/Feedback welcome! > > http://techwires.net/~bschmidt/patches/freebsd/iwn/iwn_merge_20081028.diff.bz2 This update fix my panic. And now if_iwn detect my Intel 5100BGN : iwn0: mem 0xec800000-0xec801fff irq 17 at device 0.0 on pci6 iwn0: Reserved 0x2000 bytes for rid 0x10 type 3 at 0xec800000 iwn0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 259 to local APIC 0 vector 48 iwn0: using IRQ 259 for MSI iwn0: MIMO 1T2R, MoW, address 00:16:ea:5c:6c:d8 iwn0: [MPSAFE] iwn0: [ITHREAD] iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11na MCS: 15Mbps 30Mbps 45Mbps 60Mbps 90Mbps 120Mbps 135Mbps 150Mbps 30Mbps 60Mbps 90Mbps 120Mbps 180Mbps 240Mbps 270Mbps 300Mbp s iwn0: 11ng MCS: 15Mbps 30Mbps 45Mbps 60Mbps 90Mbps 120Mbps 135Mbps 150Mbps 30Mbps 60Mbps 90Mbps 120Mbps 180Mbps 240Mbps 270Mbps 300Mbp s And now my card cat scan networks and connect to AP when i create wlan interface manually: ifconfig wlan0 create wlandev iwn0 wlanmode sta ifconfig wlan0 up /etc/rc.d/wpa_supplicant start wlan0 dhclient wlan0 But sometimes i receive error: iwn0: iwn5000_post_alive: could not configure WiMAX coexistence, error 35 iwn0: iwn_init_locked: could not initialize hardware, error 35 And adapter not work after this error kldunload if_iwn && kldload if_iwn does not fix problem, only reboot. If i add any other options to ifconfig wlan0 create (for example mode, country, or up) i always receive this error. Thanks! -- LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280 From bzeeb-lists at lists.zabbadoz.net Sat Oct 31 18:30:08 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sat Oct 31 18:30:16 2009 Subject: Hi. /31 on ethernet links In-Reply-To: References: <4AEB834D.1050907@keff.org> <20091031.090152.74670981.sthaug@nethelp.no> <20091031.110837.41706473.sthaug@nethelp.no> Message-ID: <20091031180545.C91695@maildrop.int.zabbadoz.net> On Sat, 31 Oct 2009, Randy Bush wrote: Hi, >> However, I was simply reacting to the claim that it was *supported* by >> Cisco. > > have you noticed a difference in the bug rate between things that are > 'supported by cisco' and those that just happen to be there? :) > > but you're right. i liked. our p2ps are /30s, not /31s. and we're > moving from /126 to /127. I am sorry, I couldn't resist; I hope you won't take everything at face value... though I hope you'll seriously think of some things... Oh what /30 /31 bikeshed and how old it is? I prefer to speak of p_t_p for point-to-point in contrast to p2p for peer-2-peer btw. I seem to remember that it used to be like that but unfortunately neither the vendors nor the people who are writing (IETF) specs make a difference anymore. I do not understand, though I know some, people who are not using a /64 on an Ethernet IPv6 link; may it be ptp or not. I know there is an old enough bikeshed out about that as well as some prosposed standards. /127 really sounds fighting a system to me. It's not that you couldn't address each atom in hour house already I'd wildy guess with a /48 but ... some people always have trouble freeing their mind from things that were like that 20 years and further back. Have you ever thought of limiting your scoped link-local space on Ethernet? So why do you need valid IPs on your interfaces at all? Why do you need more than a single global unicast address? Save your IPv6 addresses for the neighbour's fridges and toasters. /bz -- Bjoern A. Zeeb Even on Oct. 31st there is no candy with this mail. From iprebeg at freebsd.org Sat Oct 31 20:21:49 2009 From: iprebeg at freebsd.org (iprebeg@freebsd.org) Date: Sat Oct 31 20:21:56 2009 Subject: AR5212 wlan adapter Message-ID: <20091031201226.GA6044@valeria.zesoi.fer.hr> I have D-LINK DWA-520 adapter (AR5212 chipset) running on 8.0-BETA2 machine (same thing on -RC1). It appears as ath0 interface, but I can't get scan results. ifconfig ath0 up scan reports that it can't get scan results. When I add wpa_supplicant configuration and try to start it, it reports errors with IOCTL. Do I miss something here? Any help? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20091031/7715c925/attachment.pgp From bschmidt at techwires.net Sat Oct 31 20:34:49 2009 From: bschmidt at techwires.net (Bernhard Schmidt) Date: Sat Oct 31 20:34:56 2009 Subject: AR5212 wlan adapter In-Reply-To: <20091031201226.GA6044@valeria.zesoi.fer.hr> References: <20091031201226.GA6044@valeria.zesoi.fer.hr> Message-ID: <200910312134.47541.bschmidt@techwires.net> On Saturday 31 October 2009 21:12:26 iprebeg@freebsd.org wrote: > I have D-LINK DWA-520 adapter (AR5212 chipset) running on 8.0-BETA2 > machine (same thing on -RC1). It appears as ath0 interface, but I can't > get scan results. > ifconfig ath0 up scan > reports that it can't get scan results. > When I add wpa_supplicant configuration and try to start it, it reports > errors with IOCTL. > > Do I miss something here? > > Any help? man ath ifconfig wlan0 create wlandev ath0 ifconfig wlan0 up ifconfig wlan0 scan -- Bernhard From bschmidt at techwires.net Sat Oct 31 21:03:53 2009 From: bschmidt at techwires.net (Bernhard Schmidt) Date: Sat Oct 31 21:04:01 2009 Subject: Intel WiFi 5100/5300 In-Reply-To: <20091031174631.GA32588@expo.ukrweb.net> References: <20091009170839.142800@gmx.net> <200910300926.32286.bschmidt@techwires.net> <20091031174631.GA32588@expo.ukrweb.net> Message-ID: <200910312203.53266.bschmidt@techwires.net> On Saturday 31 October 2009 18:46:31 Mykola Dzham wrote: > But sometimes i receive error: > > iwn0: iwn5000_post_alive: could not configure WiMAX coexistence, error 35 > iwn0: iwn_init_locked: could not initialize hardware, error 35 > > And adapter not work after this error kldunload if_iwn && kldload > if_iwn does not fix problem, only reboot. > If i add any other options to ifconfig wlan0 create (for example mode, > country, or up) i always receive this error. Does it help if you add a bit of delay between kldunload and kldload? I have the feeling that your device is either still powered down or gets powered down on the way. somewhere. I'm not able to reproduce this myself, yet I'm trying. Thanks for the feedback! By the way, current iwn development is done here: http://svn.techwires.net/ -- Bernhard From kaduk at MIT.EDU Sat Oct 31 23:40:04 2009 From: kaduk at MIT.EDU (Benjamin Kaduk) Date: Sat Oct 31 23:40:10 2009 Subject: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock Message-ID: <200910312340.n9VNe372022341@freefall.freebsd.org> The following reply was made to PR kern/140036; it has been noted by GNATS. From: Benjamin Kaduk To: Bernhard Schmidt Cc: bug-followup@freebsd.org Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock Date: Sat, 31 Oct 2009 19:24:59 -0400 (EDT) Indeed, I think I saw a lockup a couple days ago, possibly when my card had dissociated and was trying to reassociate. Thanks for looking into this, -Ben On Thu, 29 Oct 2009, Bernhard Schmidt wrote: > Hi, > > Removing the IWN_LOCK(sc) leads to races when calling iwn_cmd(). It's better > to drop the IEEE80211_LOCK(ic). I do have a patch in test which hopefully will > hit the tree soon. > > -- > Bernhard >